From nobody Mon Mar 2 09:14:02 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6971A1B9C; Mon, 2 Mar 2015 09:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lt4nvYbp2ay; Mon, 2 Mar 2015 09:06:14 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677C31A0377; Mon, 2 Mar 2015 09:06:14 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id z107so5894230qgd.4; Mon, 02 Mar 2015 09:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=jgY5ctvLSZarYWIgZ6EUO1xnfW5nfHvZGSnHskxWvr0=; b=LI6Il5xhg4zUx8hLM2VMJid5IUQYVrWjJei5xo5+92X+nQx+t0BrYSgWyXnj5iHu0C PBibH7Nd6+gWJFiD1Ijmrzup+QmAtDhdZc6SfKdisjW89GCaczLyjPCkzpKQMa2hJYB0 C1o/fNTn+o4lcJey54Gh0ota1jLI//Yc8Z1SQfyahHD2MfeFjTYM0jVPtyQ9jYN1tNAI tPW41GhCO2s4yDiceGjGgqTJSQQeR+x2MZFsb4dHOsGTrD98QMxh3cM5dOZq8JDtPmcg aBq/0jUmxmUOfJtJ7ZgSfNV/+6+KpyEnaLyw+Ddo2eTQ1Es7HtVo5qGc2jYqPGoWNQR5 CSig== MIME-Version: 1.0 X-Received: by 10.55.15.202 with SMTP id 71mr7070397qkp.83.1425315973650; Mon, 02 Mar 2015 09:06:13 -0800 (PST) Received: by 10.96.92.137 with HTTP; Mon, 2 Mar 2015 09:06:13 -0800 (PST) Date: Mon, 2 Mar 2015 12:06:13 -0500 Message-ID: From: Allison Mankin To: IETF Discussion , draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11473ff84d5d980510513c9b Archived-At: X-Mailman-Approved-At: Mon, 02 Mar 2015 09:13:53 -0800 Cc: gorry@erg.abdn.ac.uk, tsv-art@ietf.org, bfcpbis@ietf.org, Transport Directorate Subject: [bfcpbis] TSVDIR LC review: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard> X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 17:06:21 -0000 --001a11473ff84d5d980510513c9b Content-Type: text/plain; charset=UTF-8 [Put into template form and forwarded for the TSVDIR reviewer, Gorry Fairhurst, to expedite while he is traveling] Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-6man-resilient-rs-04.txt Reviewer: Gorry Fairhurst Review Date: 2015-03-01 IETF LC End Date: 2015-03-05 IESG Telechat date: --- Summary: This draft is not ready for publication as a standards track RFC. This document defines a control protocol that may be used over TCP or UDP. The major change between this document and its predecessor RFC4528 is stated to be: Main purpose of this work was to revise the specification to support BFCP over an unreliable transport (Section 16.1) The use of UDP raises a number of issues that need to be considered when used in environments that may experience congestion, long delay, or limited capacity. Further work appears to be needed to address these concerns. Citing RFC 5405 as normative (rather than informational) may be good, and some of the guidance from this BCP suggests protocol issues that should be examined and justified or amended. Notable concerns are the lack of support for RTT estimation, and the way in which fragmentation is handled. There is mention of potential support for SCTP, however the statement on SCTP appears to need updating. The intro states: "BFCP has been designed so that it can be used in low- bandwidth environments" - there are specific low-bandwidth concerns when UDP is used. See below. Section 3.4: Congestion Control I do not understand how congestion-control is performed on the media flow. Is it the responsibility of each audio stream to independently react to congestion? If it is, it would be useful to state this here. Section 5: Protocol: "If a floor control server receives a message with an unsupported version field value, and the extensions in this document is supported, the receiving server MUST send an Error message with parameter value 12 (Unsupported Version) to indicate this. " - What happens in the case where the receiving server does not support the extensions in this document? Does it silently discard? 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? What is the privacy model when TLS/DTLS is not used? - Does the protocol expose the identity of participants to others on the network? "Res: At this point, the 3 bits" - This may be better written as perhaps: Res: In version 1 and 2 of the protocol, the 3 bits". Primitive - Please specify here what a receiver should do with an undefined primitive value! 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? Conference ID: - Is the Conference ID randomised to provide protection to mitigate the chance of off-path data insertion attacks? Note that in section 6.2.4, symmetric port numbers (src,dst) are recommended, and hence the a random ephemeral port does not offer protection from off-path attacks in the case where TLS/DTLS is not used. Fragment Length: - What happens if the datagram length (e.g. UDP-Length) is less or more than the value specified within the BFCP? Section 6.1: CC: "if a TCP connection cannot deliver a BFCP message and times out or receives an ICMP port unreachable message mid-connection, the TCP connection SHOULD be reestablished." - I think this needs more specification. How many times will the TCP connection be retried in succession? While it seems OK for a session to be restarted because of a delivery failure, this seems like a congestion-control problem if it is unconditionally resumed with no control of the number of attempts, and no requirement to back-off after repeated failures. Section 6.2.1: Retransmission interval: "The default initial interval MUST be set to 500ms " - The protocol appears to fail systematically when the actual path RTT is greater than 500ms. The sender needs not only to expand the timer each retransmission, but needs to avoid the possibility that every message is duplicated when the path RTT is greater than 500mS. A simple solution is for the sender learn the actual RTT and increase the default timer when this is greater than 500 mS? This seems like a protocol flaw. See RFC 5405 on the need to back-off timers, based on RTT. Section 6.2.2: How does the receiving endpoint verify that the ICMP message was from the corresponding endpoint, is there any field in the protocol header that could be used to reduce the chance of off-path attacks? Section 6.2.2: This section could usefully also refer to RFC 5405. Section 6.2.3: "BFCP entities should consider the MTU size" - This isn't capitalised as "SHOULD", was that intended? I'm unclear what the intention is here, especially when discussing PMTU-D. "and MAY run MTU discovery, such as [20][21][22], for this purpose." - Presumably this is "Path" MTU Discovery. - The ID does not explain how this is done. Could it be done using dummy messages (e.g. padded out with unused options?) or some other method to probe the path? The current text simply does not explain how PMTUD or PLPMTUD is implemented, It needs to specify how to generate a "big" packet and how to handle retransmission. Congestion Control: The protocol appears to say it sends a single datagram per RTT, but actually fragmentation may result in multiple fragments per RTT. This amplifies the congestion control risk. There appears to be no limit set to the number of fragments that may be created, and each are presumably sent as a burst - and all retransmitted if there is a single loss. This could introduce a significant risk of congestion collapse, if this happens for multiple consecutive messages. Timers T1 and T2 are set to a static value by configuration. While the values suggested may be reasonable default minimum values, these two values should be increased when a path has a larger RTT to avoid the protocol replicating all data (see RFC 5405). The current specification can increase congestion for long RTT paths, and needs to be updated to reflect paths discovered to have a larger RTT. B.1.1.6. SCTP "It would be quite straight forward to specify a BFCP binding for SCTP [28], and then tunnel SCTP over UDP in the use case described in Appendix B.1. SCTP is gaining some momentum currently. There is ongoing discussion in the RTCWeb WG regarding this approach. However, this approach for tunneling over UDP was not mature enough when considered and not even fully specified." - it seems this dismisses SCTP support, yet this text appears out of date and needs to be updated to reflect RFC 6951, and possibly https://tools.ietf.org/html/draft-ietf-tsvwg-dtls-for-sctp? --001a11473ff84d5d980510513c9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Put into template form and forwarded for the TSVDIR rev= iewer, Gorry Fairhurst, to expedite while he is traveling]
<= span style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px">
Please resolve these comments along with any other Last Ca= ll comments you may receive.

Document: =C2=A0draft-ietf-6man-resilient= -rs-04.txt
Reviewer: Gorry Fairhurst
Review Date: 2015-03-01
IETF LC = End Date: 2015-03-05
IESG Telechat date: ---

=
Summary: This draft is not ready for publication as a standards track RFC= . =C2=A0


This document defin= es a control protocol that may be used over TCP or UDP.
The = major change between this document and its predecessor RFC4528 is stated to= be:

   Main purpose of t=
his work was to revise the specification to support
   BFCP over an unreliable transport (Section 16.1)


The use of UDP raises a number of issues that need to be c= onsidered when
used in environments that may experience congestion, long = delay, or
limited capacity. Further work appears to be needed to address = these
concerns. Citing RFC 5405 as normative (rather than informational) = may be
good, and some of the guidance from this BCP suggests protocol iss= ues that
should be examined and justified or amended. Notable concerns ar= e the lack of
support for RTT estimation, and the way in which fragmentat= ion is handled.

There i= s mention of potential support for SCTP, however the statement onSCTP appears to need updating.

The intro states= :
"BFCP has been designed so that it can be used in low-
bandwidth= environments"=C2=A0- there are specific low-bandwidth
concerns when UDP is used. See below.=
Section= 3.4: Congestion Control
I do not understand how congestion-control is pe= rformed on the media flow.
Is it the responsibility of each audio stream = to independently react to
congestion? If it is, it would be useful to sta= te this here.

Section 5: Protocol:
"If a floor control server receive= s a
message with an unsupported version field value, and the extensions
in this document is supported, the receiving server MUST send anError m= essage with parameter value 12 (Unsupported Version) to
indicate this. &q= uot;
- What happens in the case where the receiving server does not suppo= rt the
extensions in this document? Does it silently discard?

Section 5:

<= span style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px">Wh= at is the security model when TLS/DTLS is not used? - has the protocol
<= span style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px">pr= otection from off-path attacks, and how is this provided?

What is the priv= acy model when TLS/DTLS is not used?=C2=A0 - Does the protocol
expose the= identity of participants to others on the network?

"Res: At this point= , the 3 bits"
- This may be better written as perhaps: Res: In versi= on 1 and 2 of the
protocol, the 3 bits".

Primitive
- Please specify= here what a receiver should do with an undefined=C2=A0primitive va= lue!

Payload Length:
- What happens when using a datagram format if the da= tagram length (e.g.
UDP-Length) is less or more than the value specified = within the BFCP?

Conference ID:
- Is the Conference ID randomised to provi= de protection to mitigate the
chance of off-path data insertion attacks? = Note that in section 6.2.4,
symmetric port numbers (src,dst) are recommen= ded, and hence the a random
ephemeral port does not offer protection from= off-path attacks in the case
where TLS/DTLS is not used.

Fragment Length:=
- What happens if the datagram length (e.g. UDP-Length) is less or more<= /span>
than the value specified within the BFCP?

Section 6.1: CC:
"if a T= CP
connection cannot deliver a BFCP message and times out or receives an<= /span>
ICMP port unreachable message mid-connection, the TCP connectionSHOULD= be reestablished."
- I think this needs more specification. How man= y times will the TCP
connection be retried in succession? While it seems = OK for a session to be
restarted because of a delivery failure, this seem= s like a
congestion-control problem if it is unconditionally resumed with= no
control of the number of attempts, and no requirement to back-off aft= er
repeated failures.

Section 6.2.1: Retransmission interval:
"The = default initial interval MUST be set to 500ms "
- The protocol appea= rs to fail systematically=C2=A0 when the actual path RTT is
greater than= 500ms. The sender needs not only to expand the timer each
retransmissi= on, but needs to avoid the possibility that every message is
duplicated w= hen the path RTT is greater than 500mS. A simple solution is
for the send= er learn the actual RTT and increase the default timer when
this is grea= ter than 500 mS? This seems like a protocol flaw. See RFC 5405
on the nee= d to back-off timers, based on RTT.

Section 6.2.2:
How does the receiving = endpoint verify that the ICMP message was from the
corresponding endpoint= , is there any field in the protocol header that
could be used to reduce = the chance of off-path attacks?

Section 6.2.2:
This section could usefully= also refer to RFC 5405.

Section 6.2.3:
"BFCP entities should conside= r the MTU size"
- This isn't capitalised as "SHOULD", = was that intended? I'm unclear what
the intention is here, especially= when discussing PMTU-D.

"and MAY run MTU discovery, such as [20][21][2= 2], for this purpose."
- Presumably this is "Path" MTU Dis= covery.
- The ID does not explain how this is done. Could it be done usin= g dummy
messages (e.g. padded out with unused options?) or some other met= hod to
probe the path? The current text simply does not explain how PMTUD= =C2=A0 or
PLPMTUD is implemented, It needs to specify how to generate a &= quot;big" packet
and how to handle retransmission.

Congestion Contr= ol:
The protocol appears to say it sends a single datagram per RTT, but
actually fragmentation may result in multiple fragments per RTT. This
<= span style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px">am= plifies the congestion control risk. There appears to be no limit set to
= the number of fragments that may be created, and each are presumably sent
as a burst - and all retransmitted if there is a single loss. This could
introduce a significant risk of congestion collapse, if this happens for
multiple consecutive messages.

Timers T1 and T2 are set to a static value b= y configuration. While the
values suggested may be reasonable default min= imum values, these two
values should be increased when a path has a large= r RTT to avoid the
protocol replicating all data (see RFC 5405). The curr= ent specification
can increase congestion for long RTT paths, and needs t= o be updated to
reflect paths discovered to have a larger RTT.

B.1.1.6.=C2= =A0 SCTP
"It would be quite straight forward to specify a BFCP bindi= ng for SCTP
[28], and then tunnel SCTP over UDP in the use case described= in
Appendix B.1.=C2=A0 SCTP is gaining some momentum currently.=C2=A0 Th= ere is ongoing
discussion in the RTCWeb WG regarding this approach. Howev= er, this
approach for tunneling over UDP was not mature enough=C2=A0 when= considered and
not even fully specified."
- it seems this dismiss= es SCTP support, yet this text appears out of date
and needs=C2=A0 to be = updated to reflect RFC 6951, and possibly
https://tools.ietf.org/= html/draft-ietf-tsvwg-dtls-for-sctp?
--001a11473ff84d5d980510513c9b-- From nobody Mon Mar 2 09:20:49 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87A91A875E; Mon, 2 Mar 2015 09:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATowFmKGt0PA; Mon, 2 Mar 2015 09:19:33 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44971A1BBD; Mon, 2 Mar 2015 09:19:31 -0800 (PST) X-AuditID: c6180641-f796f6d000004ccc-b0-54f43ad9061c Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 25.59.19660.9DA34F45; Mon, 2 Mar 2015 11:26:34 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Mon, 2 Mar 2015 12:19:26 -0500 From: Suresh Krishnan To: "draft-ietf-bfcpbis-rfc4582bis.all@tools.ietf.org" , General Area Review Team Thread-Topic: Gen-ART Telechat review of draft-ietf-bfcpbis-rfc4582bis-13.txt Thread-Index: AdBVDQfco5ClLiVFT6ins7inexpUqg== Date: Mon, 2 Mar 2015 17:19:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXSPn+4tqy8hBjMO8Vj8W3eUyeLU04ss FldffWZxYPZYsuQnk8eXy5/ZApiiuGxSUnMyy1KL9O0SuDLmnt3IUrBOsGLHpJvsDYyNfF2M nBwSAiYSz1v7mCFsMYkL99azgdhCAkcYJXYdsICwlzFKTG7SBrHZgOo37PzM1MXIxSEiMItR 4uKc3YwgCWYBTYmrh3eB2cICHhLtS++zg9giAr4S547NYIOw9ST2LGxjArFZBFQkDkw9Ahbn BaqZtfEtC4jNCHTE91NrmCBmikvcejKfCeI4AYkle85DHSoq8fLxP1YIW0ni4+/57BD1OhIL dn9ig7C1JZYtfM0MMV9Q4uTMJywTGEVmIRk7C0nLLCQts5C0LGBkWcXIUVqcWpabbmS4iREY /sck2Bx3MC74ZHmIUYCDUYmHd0Pi5xAh1sSy4srcQ4zSHCxK4rxlVw6GCAmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamBkyjjZkLLu1dOs3vZcpcJPOoVMvwseCNVsLqyoOvBnm8ncR8eWKX39 98PK5PlEN7tlMYw2HLezPnWkOSzbqXLp0qG/n05uqvk+W08v/u/rDywv2W5vU9yTeVPn/tnc M4wNfHlcPJzTjf/LX9u0nEs3fn9F1oq34bn3ni+YecNRf281k7nsFq+nSizFGYmGWsxFxYkA 0aolZmACAAA= Archived-At: X-Mailman-Approved-At: Mon, 02 Mar 2015 09:20:48 -0800 Cc: "bfcpbis@ietf.org" Subject: [bfcpbis] Gen-ART Telechat review of draft-ietf-bfcpbis-rfc4582bis-13.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 17:19:36 -0000 I am the assigned Gen-ART reviewer for this draft. For background on=0A= Gen-ART, please see the FAQ at=0A= =0A= =0A= Please wait for direction from your document shepherd or AD before =0A= posting a new version of the draft.=0A= =0A= Document: draft-ietf-bfcpbis-rfc4582bis-13.txt=0A= Reviewer: Suresh Krishnan=0A= Review Date: 2015/03/02=0A= IESG Telechat date: 2015/03/05=0A= =0A= Summary: This draft has significant issues that needs to be fixed before = =0A= it is ready for publication as a Proposed Standard.=0A= =0A= Major:=0A= =0A= * Section 5.1:=0A= =0A= This section mandates the receiver to ignore the F bit if it is set =0A= while running over reliable transport. In my opinion this is not =0A= sufficient as the length of the header is determined by the bit being =0A= set. I strongly believe that this is an error condition and the packet =0A= should not be processed further. At the bare minimum, the draft needs to = =0A= specify if the receiver should process the COMMON-HEADER as having 12 =0A= octets or 16 octets in this case.=0A= =0A= * Section 6.2.3:=0A= =0A= This section does not explicitly state that each of the fragments needs =0A= to have the COMMON-HEADER included, but it can be inferred since that is = =0A= the most logical thing to do. I would prefer that it be explicitly =0A= stated though.=0A= =0A= If my interpretation is correct, then the formula for calculating the =0A= number of fragments is wrong. Instead of=0A= =0A= N=3Dceil(message size / MTU size)=0A= =0A= it needs to be=0A= =0A= N =3D ceil( (message size - X) / (MTU size - X) )=0A= =0A= where X is the size of the COMMON-HEADER with fragment fields (i.e. 16) =0A= if the MTU size is the MTU for UDP. This is needed because the common =0A= header will be repeated on all the fragments.=0A= =0A= e.g. Assume MTU size=3D1280 and message size=3D2560 (COMMON-HEADER 16 + 254= 4 =0A= message) the current formula will yield N=3D2, while N should in fact be 3 = =0A= as the message will not fit in 2 fragments.=0A= =0A= Thanks=0A= Suresh=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= From nobody Mon Mar 2 10:45:54 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382FC1A700B; Mon, 2 Mar 2015 10:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85vc9GWuWbtU; Mon, 2 Mar 2015 10:42:29 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F8E1A88C9; Mon, 2 Mar 2015 10:42:29 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t22IgT7n011179; Mon, 2 Mar 2015 18:42:29 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 9AD23C207CA; Mon, 2 Mar 2015 18:42:29 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150219174215.4401.59106.idtracker@ietfa.amsl.com> References: <20150219174215.4401.59106.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #809493 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 02 Mar 2015 18:42:29 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 02 Mar 2015 10:45:53 -0800 Cc: draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, iesg@ietf.org, bfcpbis-chairs@ietf.org Subject: [bfcpbis] [IANA #809493] Last Call: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 18:42:34 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-bfcpbis-rfc4582bis-13. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA has some questions about the IANA actions requested in this draft. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document there are four actions which IANA must complete. First, the document directs IANA to establish a Attribute subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at: http://www.iana.org/assignments/bfcp-parameters/ IANA observes that the initial values provided in the document being considered are already in the existing Attribute subregistry. Thus: - IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ]. - This draft revises the registration procedure from "Standards-Track RFC" to "Specification Required" as defined in RFC5226. Please note that Specification Required, when used, also implies use of a Designated Expert. Questions: Is value 0 the first value of BFCP attributes? And if so, should value 0 be marked as Reserved in the registry? Is there a maximum value of this registry? 32-bit? Or is this an unlimited resource registry? Second, the document directs IANA to establish a Primitive subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at: http://www.iana.org/assignments/bfcp-parameters/ IANA observes that the initial values provided in the document being considered, with four exceptions, are already in the existing Primitive subregistry. Thus: - IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ]. - This draft revises the registration procedure from "Standards-Track RFC" to "Specification Required" as defined in RFC5226. Please note that Specification Required, when used, also implies use of a Designated Expert. - In addition, IANA will add four new values to the registry as follows: Value: 14 Primitive: FloorRequestStatusAck Reference: [ RFC-to-be ] Value: 15 Primitive: FloorStatusAck Reference: [ RFC-to-be ] Value: 16 Primitive: Goodbye Reference: [ RFC-to-be ] Value: 17 Primitive: GoodbyeAck Reference: [ RFC-to-be ] Questions: Is value 0 the first value of BFCP primitives? And if so, should value 0 be marked as Reserved in the registry? Is there a maximum value for this registry? Or is this an unlimited resource registry? Third, the document directs IANA to establish a Request Status subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at: http://www.iana.org/assignments/bfcp-parameters/ IANA observes that the initial values provided in the document being considered, are already in the existing Request Status subregistry. Thus: - IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ]. - This draft revises the registration procedure from "Standards-Track RFC" to "Specification Required" as defined in RFC5226. Please note that Specification Required, when used, also implies use of a Designated Expert. Questions: Is value 0 the first value of BFCP request status values? And if so, should value 0 be marked as Reserved in the registry? Is there a maximum value for this registry? 8-bit? Or is this an unlimited resource registry? Fourth, the document directs IANA to establish a Error Code subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at: http://www.iana.org/assignments/bfcp-parameters/ IANA observes that the initial values provided in the document being considered, with five exceptions, are already in the existing Error Code subregistry. Thus: - IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ]. - This draft revises the registration procedure from "Standards-Track RFC" to "Specification Required" as defined in RFC5226. Please note that Specification Required, when used, also implies use of a Designated Expert. - In addition, IANA will add five new values to the registry as follows: Value: 10 Meaning: Unable to parse message Reference: [ RFC-to-be ] Value: 11 Meaning: Use DTLS Reference: [ RFC-to-be ] Value: 12 Meaning: Unsupported Version Reference: [ RFC-to-be ] Value: 13 Meaning: Incorrect Message Length Reference: [ RFC-to-be ] Value: 14 Meaning: Generic Error Reference: [ RFC-to-be ] Questions: Is value 0 the first value of BFCP request status values? And if so, should value 0 be marked as Reserved in the registry? Is there a maximum value for this registry? 32-bit? Or is this an unlimited resource registry? IANA understands that these four actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Thu Feb 19 17:42:40 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Binary Floor Control Protocol > Bis WG (bfcpbis) to consider the following document: > - 'The Binary Floor Control Protocol (BFCP)' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-03-05. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Floor control is a means to manage joint or exclusive access to > shared resources in a (multiparty) conferencing environment. > Thereby, floor control complements other functions -- such as > conference and media session setup, conference policy manipulation, > and media control -- that are realized by other protocols. > > This document specifies the Binary Floor Control Protocol (BFCP). > BFCP is used between floor participants and floor control servers, > and between floor chairs (i.e., moderators) and floor control > servers. > > This document obsoletes RFC 4582. Changes from RFC 4582 are > summarized in Section 16. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Mon Mar 2 10:45:56 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 620021A889D; Mon, 2 Mar 2015 10:42:34 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382FC1A700B; Mon, 2 Mar 2015 10:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85vc9GWuWbtU; Mon, 2 Mar 2015 10:42:29 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F8E1A88C9; Mon, 2 Mar 2015 10:42:29 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t22IgT7n011179; Mon, 2 Mar 2015 18:42:29 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 9AD23C207CA; Mon, 2 Mar 2015 18:42:29 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150219174215.4401.59106.idtracker@ietfa.amsl.com> References: <20150219174215.4401.59106.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #809493 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 02 Mar 2015 18:42:29 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 02 Mar 2015 10:45:54 -0800 Cc: draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, iesg@ietf.org, bfcpbis-chairs@ietf.org Subject: [bfcpbis] [IANA #809493] Last Call: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 18:42:34 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-bfcpbis-rfc4582bis-13. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA has some questions about the IANA actions requested in this draft. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document there are four actions which IANA must complete. First, the document directs IANA to establish a Attribute subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at: http://www.iana.org/assignments/bfcp-parameters/ IANA observes that the initial values provided in the document being considered are already in the existing Attribute subregistry. Thus: - IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ]. - This draft revises the registration procedure from "Standards-Track RFC" to "Specification Required" as defined in RFC5226. Please note that Specification Required, when used, also implies use of a Designated Expert. Questions: Is value 0 the first value of BFCP attributes? And if so, should value 0 be marked as Reserved in the registry? Is there a maximum value of this registry? 32-bit? Or is this an unlimited resource registry? Second, the document directs IANA to establish a Primitive subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at: http://www.iana.org/assignments/bfcp-parameters/ IANA observes that the initial values provided in the document being considered, with four exceptions, are already in the existing Primitive subregistry. Thus: - IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ]. - This draft revises the registration procedure from "Standards-Track RFC" to "Specification Required" as defined in RFC5226. Please note that Specification Required, when used, also implies use of a Designated Expert. - In addition, IANA will add four new values to the registry as follows: Value: 14 Primitive: FloorRequestStatusAck Reference: [ RFC-to-be ] Value: 15 Primitive: FloorStatusAck Reference: [ RFC-to-be ] Value: 16 Primitive: Goodbye Reference: [ RFC-to-be ] Value: 17 Primitive: GoodbyeAck Reference: [ RFC-to-be ] Questions: Is value 0 the first value of BFCP primitives? And if so, should value 0 be marked as Reserved in the registry? Is there a maximum value for this registry? Or is this an unlimited resource registry? Third, the document directs IANA to establish a Request Status subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at: http://www.iana.org/assignments/bfcp-parameters/ IANA observes that the initial values provided in the document being considered, are already in the existing Request Status subregistry. Thus: - IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ]. - This draft revises the registration procedure from "Standards-Track RFC" to "Specification Required" as defined in RFC5226. Please note that Specification Required, when used, also implies use of a Designated Expert. Questions: Is value 0 the first value of BFCP request status values? And if so, should value 0 be marked as Reserved in the registry? Is there a maximum value for this registry? 8-bit? Or is this an unlimited resource registry? Fourth, the document directs IANA to establish a Error Code subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at: http://www.iana.org/assignments/bfcp-parameters/ IANA observes that the initial values provided in the document being considered, with five exceptions, are already in the existing Error Code subregistry. Thus: - IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ]. - This draft revises the registration procedure from "Standards-Track RFC" to "Specification Required" as defined in RFC5226. Please note that Specification Required, when used, also implies use of a Designated Expert. - In addition, IANA will add five new values to the registry as follows: Value: 10 Meaning: Unable to parse message Reference: [ RFC-to-be ] Value: 11 Meaning: Use DTLS Reference: [ RFC-to-be ] Value: 12 Meaning: Unsupported Version Reference: [ RFC-to-be ] Value: 13 Meaning: Incorrect Message Length Reference: [ RFC-to-be ] Value: 14 Meaning: Generic Error Reference: [ RFC-to-be ] Questions: Is value 0 the first value of BFCP request status values? And if so, should value 0 be marked as Reserved in the registry? Is there a maximum value for this registry? 32-bit? Or is this an unlimited resource registry? IANA understands that these four actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Thu Feb 19 17:42:40 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Binary Floor Control Protocol > Bis WG (bfcpbis) to consider the following document: > - 'The Binary Floor Control Protocol (BFCP)' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-03-05. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Floor control is a means to manage joint or exclusive access to > shared resources in a (multiparty) conferencing environment. > Thereby, floor control complements other functions -- such as > conference and media session setup, conference policy manipulation, > and media control -- that are realized by other protocols. > > This document specifies the Binary Floor Control Protocol (BFCP). > BFCP is used between floor participants and floor control servers, > and between floor chairs (i.e., moderators) and floor control > servers. > > This document obsoletes RFC 4582. Changes from RFC 4582 are > summarized in Section 16. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Mon Mar 2 17:09:37 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1DD061A9006; Mon, 2 Mar 2015 17:05:16 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC9A1A9005 for ; Mon, 2 Mar 2015 17:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYV-2XvvpsWd for ; Mon, 2 Mar 2015 17:05:14 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E7F1A8F4F for ; Mon, 2 Mar 2015 17:05:11 -0800 (PST) Received: from usevmg21.ericsson.net ([198.24.6.65]:48922) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YSbGp-0001z9-11 for draft-ietf-bfcpbis-rfc4582bis.all@tools.ietf.org; Mon, 02 Mar 2015 17:05:11 -0800 X-AuditID: c6180641-f796f6d000004ccc-b0-54f43ad9061c Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 25.59.19660.9DA34F45; Mon, 2 Mar 2015 11:26:34 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Mon, 2 Mar 2015 12:19:26 -0500 From: Suresh Krishnan To: "draft-ietf-bfcpbis-rfc4582bis.all@tools.ietf.org" , General Area Review Team Thread-Topic: Gen-ART Telechat review of draft-ietf-bfcpbis-rfc4582bis-13.txt Thread-Index: AdBVDQfco5ClLiVFT6ins7inexpUqg== Date: Mon, 2 Mar 2015 17:19:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXSPn+4tqy8hBjMO8Vj8W3eUyeLU04ss FldffWZxYPZYsuQnk8eXy5/ZApiiuGxSUnMyy1KL9O0SuDLmnt3IUrBOsGLHpJvsDYyNfF2M nBwSAiYSz1v7mCFsMYkL99azgdhCAkcYJXYdsICwlzFKTG7SBrHZgOo37PzM1MXIxSEiMItR 4uKc3YwgCWYBTYmrh3eB2cICHhLtS++zg9giAr4S547NYIOw9ST2LGxjArFZBFQkDkw9Ahbn BaqZtfEtC4jNCHTE91NrmCBmikvcejKfCeI4AYkle85DHSoq8fLxP1YIW0ni4+/57BD1OhIL dn9ig7C1JZYtfM0MMV9Q4uTMJywTGEVmIRk7C0nLLCQts5C0LGBkWcXIUVqcWpabbmS4iREY /sck2Bx3MC74ZHmIUYCDUYmHd0Pi5xAh1sSy4srcQ4zSHCxK4rxlVw6GCAmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamBkyjjZkLLu1dOs3vZcpcJPOoVMvwseCNVsLqyoOvBnm8ncR8eWKX39 98PK5PlEN7tlMYw2HLezPnWkOSzbqXLp0qG/n05uqvk+W08v/u/rDywv2W5vU9yTeVPn/tnc M4wNfHlcPJzTjf/LX9u0nEs3fn9F1oq34bn3ni+YecNRf281k7nsFq+nSizFGYmGWsxFxYkA 0aolZmACAAA= X-SA-Exim-Connect-IP: 198.24.6.65 X-SA-Exim-Rcpt-To: draft-ietf-bfcpbis-rfc4582bis.all@tools.ietf.org X-SA-Exim-Mail-From: suresh.krishnan@ericsson.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-bfcpbis-rfc4582bis.all@ietf.org Resent-Message-Id: <20150303010514.B1E7F1A8F4F@ietfa.amsl.com> Resent-Date: Mon, 2 Mar 2015 17:05:11 -0800 (PST) Resent-From: suresh.krishnan@ericsson.com Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 02 Mar 2015 17:09:35 -0800 Cc: "bfcpbis@ietf.org" Subject: [bfcpbis] Gen-ART Telechat review of draft-ietf-bfcpbis-rfc4582bis-13.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 01:05:16 -0000 I am the assigned Gen-ART reviewer for this draft. For background on=0A= Gen-ART, please see the FAQ at=0A= =0A= =0A= Please wait for direction from your document shepherd or AD before =0A= posting a new version of the draft.=0A= =0A= Document: draft-ietf-bfcpbis-rfc4582bis-13.txt=0A= Reviewer: Suresh Krishnan=0A= Review Date: 2015/03/02=0A= IESG Telechat date: 2015/03/05=0A= =0A= Summary: This draft has significant issues that needs to be fixed before = =0A= it is ready for publication as a Proposed Standard.=0A= =0A= Major:=0A= =0A= * Section 5.1:=0A= =0A= This section mandates the receiver to ignore the F bit if it is set =0A= while running over reliable transport. In my opinion this is not =0A= sufficient as the length of the header is determined by the bit being =0A= set. I strongly believe that this is an error condition and the packet =0A= should not be processed further. At the bare minimum, the draft needs to = =0A= specify if the receiver should process the COMMON-HEADER as having 12 =0A= octets or 16 octets in this case.=0A= =0A= * Section 6.2.3:=0A= =0A= This section does not explicitly state that each of the fragments needs =0A= to have the COMMON-HEADER included, but it can be inferred since that is = =0A= the most logical thing to do. I would prefer that it be explicitly =0A= stated though.=0A= =0A= If my interpretation is correct, then the formula for calculating the =0A= number of fragments is wrong. Instead of=0A= =0A= N=3Dceil(message size / MTU size)=0A= =0A= it needs to be=0A= =0A= N =3D ceil( (message size - X) / (MTU size - X) )=0A= =0A= where X is the size of the COMMON-HEADER with fragment fields (i.e. 16) =0A= if the MTU size is the MTU for UDP. This is needed because the common =0A= header will be repeated on all the fragments.=0A= =0A= e.g. Assume MTU size=3D1280 and message size=3D2560 (COMMON-HEADER 16 + 254= 4 =0A= message) the current formula will yield N=3D2, while N should in fact be 3 = =0A= as the message will not fit in 2 fragments.=0A= =0A= Thanks=0A= Suresh=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= From nobody Tue Mar 3 06:21:56 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6352F1A026A for ; Mon, 2 Mar 2015 19:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_hfmLXAR29p for ; Mon, 2 Mar 2015 19:24:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779411A020A for ; Mon, 2 Mar 2015 19:24:10 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t233NxdF089940 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2015 21:24:09 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: "Ben Campbell" To: "draft-ietf-bfcpbis-rfc4582bis.all@tools.ietf.org" Date: Mon, 02 Mar 2015 21:23:58 -0600 Message-ID: <8B1B0603-B1DE-4A68-B196-19BE90F600DB@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9r5066) Archived-At: X-Mailman-Approved-At: Tue, 03 Mar 2015 06:21:48 -0800 Cc: Richard Barnes , bfcpbis@ietf.org Subject: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-13 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 03:24:12 -0000 (no hats—please treat as any other IETF last call feedback) Hi, Here are some comments on draft-ietf-bfcpbis-rfc4582bis-13. I've divided them into substantive and editorial comments. I've tried to limit comments to the actual "bis" parts, but I don't know how successful I've been at that. Thanks! Ben. *** substantive comments *** — 5.1, "ver" Am I correct that the guidance for receiving an unsupported version applies when you get the wrong version for the transport? (even if you might have supported that version on a different transport?) If so, it would be good to mention that. Also it would be nice to elaborate a bit more on the case of a device only supporting 4582. Given that you aren't allowed to send version 1 over UDP, how would this ever be an issue? Are you worried about early UDP implementations that still use version 1? If so, that would be worth a note. — 5.1, payload length: How is a TCP recipient expected to know a payload length was wrong? (Other than the parser failing on the next message?) Also, in the "note", what is the "message size" for a fragmented message over UDP? Is it the size of a fragment, or the size of the message before fragmentation plus the additional common headers? In either case, the REQUIRED part seems more a statement of fact (i.e. you mathematically can't express a size that won't fit) than a normative requirement. 5.3.11: It seems like "Hello" does quite a bit more than liveness checks. (e.g., establishing the connection for UDP, capabilities query). Also, if Hello is used for liveness checks, I missed any discussion about the procedures for using it for that purpose. (Note that 6.2.4 says to use STUN for liveness checks for non-reliable transports.) -- 6.2.1: Is this section only applicable to non-reliable transports? Also, the bit about only sending one message until you get an ack is not quite true even for UDP if you consider fragmented messages. -- 6.2.1, last paragraph: Can you elaborate on what it means to say the "default MUST be" a certain value? Do you mean an implementation MUST use that for a default if no other value is selected? Or is this more a statement of fact (the default value _is_...)? -- 6.2.3, paragraph 5: "The Fragment Offset field denotes the number of bytes..." The definition said the unit was 4-octet units. -- 8: If a request times out completely on a non-reliable transport, does that impact the state of the "bfcp connection"? -- 9.1: The text mentions sending self-signed certs or fingerprints in an "initial integrity protected channel". I assume that means the signaling protocol? The language does not seem to allow for a CA issued certs validated with PKI techniques. Is that the intent? If so, can they be mixed and matched? (i.e. a self-signed client cert and a CA issued server cert?) 13.1.1, last paragraph: What if the Ack is never received? What if it is received after T2 expires? (In the latter case, does the device need to be prepared to receive an Ack for which it no longer has transaction state?) 13.7, paragraph 2: Is the normative requirement to send an error 12 if you don't support the version redundant with similar normative language in the definition of "ver"? -- section 14, last sentence: I think you mean to require the use of encryption if TLS/DTLS is used, but the language can be read to globally require TLS/DTLS, which is not consistent with guidance elsewhere. -- Appendix A: For non-reliable transports, do both endpoints share a transaction ID sequence, or does each end keep it's own independent sequence? I would have guessed the latter, but in step 5 of the example, the server originated transaction has a transaction ID that is one higher than the latest value sent by the client. -- Note following Figure 48: "... does not and SHOULD not" That's an odd construction. Do you mean a statement of fact, or a normative requirement? If the latter, why is this a SHOULD and not a MUST? Can you imagine a situation where it might be valid for the client to ack the initial FloorRequestStatus message? *** editorial comments *** — section 3, 1st paragraph: The bis version considers new requirements beyond those mentioned, doesn't it? (e.g., UDP support?) It would be nice to mention that here. — 4.1, paragraph 7: I'm a bit surprised to see the unreliable transport message flows buried in an appendix. Aren't those the whole point of the update? — 5.1, Res: The phrase "At this point," doesn't seem to add anything, and may confuse readers. —5.2, "M" bit: The phrase "In all other cases,..." is a little ambiguous. I assume you mean "Attributes specified in future extensions that do not have the "M" bit set..." From nobody Tue Mar 3 06:22:30 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3DDE31A0141; Mon, 2 Mar 2015 19:10:06 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103331A0137; Mon, 2 Mar 2015 19:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCPy8WS6yW-k; Mon, 2 Mar 2015 19:10:04 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D141A0141; Mon, 2 Mar 2015 19:09:55 -0800 (PST) X-AuditID: c618062d-f79876d000003ebd-f9-54f4d162b714 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 0D.26.16061.261D4F45; Mon, 2 Mar 2015 22:08:50 +0100 (CET) Received: from [153.88.4.49] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.93) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 2 Mar 2015 22:09:53 -0500 Message-ID: <54F525FB.3050107@ericsson.com> Date: Mon, 2 Mar 2015 22:09:47 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: , General Area Review Team References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyuXRPrG7SxS8hBovfSVgcOfubxeLqq88s DkweS5b8ZApgjOKySUnNySxLLdK3S+DKWHbsKUvBJ+GKzhdLWRsY+wW6GDk5JARMJLa8/c0G YYtJXLi3Hsjm4hASOMIosf72SVYIZxOjxPlrV1hAqngFtCU+3T3MBGKzCKhIvJ79mBHEZgOa tGHnZ7C4qECYxPfNO5gh6gUlTs58AtYrIhAvsaD9LpgtLBAu8fh1IyuILSTgK/HsUitQnIOD U8BPYsbkQBBTQiBS4vcudRCTWcBe4sHWMpBiZgF5ie1v5zBDNGpKbF3znRXifEWJF8d/Mk1g FJqFZO8shO5ZSLoXMDKvYuQoLU4ty003MtjECAzOYxJsujsY97y0PMQowMGoxMNrsPlLiBBr YllxZe4hRmkOFiVx3kUPDoYICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYAyz3CV38diOI85q a/V7zxje4l0/u3vx3NCkiw6vgx9ZuiiqXvrgNlPjcaGthWzDCSOnF+dk7lSphi7fIyp4Kbze PXFVrUykvlfwBOs5ITbZiofWCi1YKbt58rPYZ0VJCyqD3I5/v1tQyR6fGfVQ71ngoU2tDz23 J92ev60h0aVzl8EVYVu280osxRmJhlrMRcWJALIfJkYvAgAA Archived-At: X-Mailman-Approved-At: Tue, 03 Mar 2015 06:22:28 -0800 Subject: [bfcpbis] Fwd: [Gen-art] Gen-ART Telechat review of draft-ietf-bfcpbis-rfc4582bis-13.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 03:10:06 -0000 Resending as there seems to be some issue with the tools aliases. -------- Forwarded Message -------- Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-bfcpbis-rfc4582bis-13.txt Date: Mon, 2 Mar 2015 17:19:26 +0000 From: Suresh Krishnan To: draft-ietf-bfcpbis-rfc4582bis.all@tools.ietf.org , General Area Review Team CC: bfcpbis@ietf.org I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-bfcpbis-rfc4582bis-13.txt Reviewer: Suresh Krishnan Review Date: 2015/03/02 IESG Telechat date: 2015/03/05 Summary: This draft has significant issues that needs to be fixed before it is ready for publication as a Proposed Standard. Major: * Section 5.1: This section mandates the receiver to ignore the F bit if it is set while running over reliable transport. In my opinion this is not sufficient as the length of the header is determined by the bit being set. I strongly believe that this is an error condition and the packet should not be processed further. At the bare minimum, the draft needs to specify if the receiver should process the COMMON-HEADER as having 12 octets or 16 octets in this case. * Section 6.2.3: This section does not explicitly state that each of the fragments needs to have the COMMON-HEADER included, but it can be inferred since that is the most logical thing to do. I would prefer that it be explicitly stated though. If my interpretation is correct, then the formula for calculating the number of fragments is wrong. Instead of N=ceil(message size / MTU size) it needs to be N = ceil( (message size - X) / (MTU size - X) ) where X is the size of the COMMON-HEADER with fragment fields (i.e. 16) if the MTU size is the MTU for UDP. This is needed because the common header will be repeated on all the fragments. e.g. Assume MTU size=1280 and message size=2560 (COMMON-HEADER 16 + 2544 message) the current formula will yield N=2, while N should in fact be 3 as the message will not fit in 2 fragments. Thanks Suresh _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Mar 3 16:58:13 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648F51A89AB for ; Tue, 3 Mar 2015 16:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw9OK8wiMKxx for ; Tue, 3 Mar 2015 16:58:07 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B74E1A8943 for ; Tue, 3 Mar 2015 16:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40714; q=dns/txt; s=iport; t=1425430688; x=1426640288; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=gLxFd753YogKATODKa4lhfgTMV3chiDZ80SzMoYBcLE=; b=ejfB6TQ80tg/CN11wSWfVM3Sv9+vQneoQIG5Csj7UN2yoN5SmTlWZDW6 QYqROPLIw4LNPgTDPDDuNdsMuvyOcdwoRucMVxAWKVxqZrek5wSaUFO5j tPq1fye9swepe4ENhhJTgBNg+q3ftu27xygga8mHi7kyRP5ovTZR1rq5W E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DZBgACWPZU/4oNJK1RCYI/Q1Jeu02FeYVwAoEnTQEBAQEBAXyEDwEBAQRoBB0CAQgRAwECIQECBAchERQHAQEFAwIEExuIAAMRDdEmDYUeAQEBAQEBBAEBAQEBAQEXBIsSgkSBSAcDAQYBPw0LBoQlBY95g2CEIYFIgRqDIoJThkWGDCOCAhwUgTxvgQIBCBcifwEBAQ X-IronPort-AV: E=Sophos;i="5.09,684,1418083200"; d="scan'208,217";a="128651803" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 04 Mar 2015 00:58:07 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t240w6U2021011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Mar 2015 00:58:06 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.45]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 18:58:06 -0600 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: TSVDIR LC review: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard> Thread-Index: AQHQVQtGt/CRNze8K0KHaaVOidh9uZ0LYOuA Date: Wed, 4 Mar 2015 00:58:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.22.181] Content-Type: multipart/alternative; boundary="_000_D11B981A407F4eckelcuciscocom_" MIME-Version: 1.0 Archived-At: Subject: [bfcpbis] FW: TSVDIR LC review: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard> X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 00:58:11 -0000 --_000_D11B981A407F4eckelcuciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forwarding to list because I do not believe it made it through originally. Note, the document name in the email text should have read draft-ietf-bfcpb= is-rfc4582bis-13.txt, not draft-ietf-6man-resilient-rs-04.txt Cheers, Charles From: Allison Mankin > Date: Monday, March 2, 2015 at 11:06 AM To: "ietf@ietf.org" >, "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" > Cc: Transport Directorate >, "gor= ry@erg.abdn.ac.uk" >, >, "bfc= pbis@ietf.org" > Subject: TSVDIR LC review: (The Bina= ry Floor Control Protocol (BFCP)) to Proposed Standard> [Put into template form and forwarded for the TSVDIR reviewer, Gorry Fairhu= rst, to expedite while he is traveling] Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-6man-resilient-rs-04.txt Reviewer: Gorry Fairhurst Review Date: 2015-03-01 IETF LC End Date: 2015-03-05 IESG Telechat date: --- Summary: This draft is not ready for publication as a standards track RFC. This document defines a control protocol that may be used over TCP or UDP. The major change between this document and its predecessor RFC4528 is state= d to be: Main purpose of this work was to revise the specification to support BFCP over an unreliable transport (Section 16.1) The use of UDP raises a number of issues that need to be considered when used in environments that may experience congestion, long delay, or limited capacity. Further work appears to be needed to address these concerns. Citing RFC 5405 as normative (rather than informational) may be good, and some of the guidance from this BCP suggests protocol issues that should be examined and justified or amended. Notable concerns are the lack = of support for RTT estimation, and the way in which fragmentation is handled. There is mention of potential support for SCTP, however the statement on SCTP appears to need updating. The intro states: "BFCP has been designed so that it can be used in low- bandwidth environments" - there are specific low-bandwidth concerns when UDP is used. See below. Section 3.4: Congestion Control I do not understand how congestion-control is performed on the media flow. Is it the responsibility of each audio stream to independently react to congestion? If it is, it would be useful to state this here. Section 5: Protocol: "If a floor control server receives a message with an unsupported version field value, and the extensions in this document is supported, the receiving server MUST send an Error message with parameter value 12 (Unsupported Version) to indicate this. " - What happens in the case where the receiving server does not support the extensions in this document? Does it silently discard? 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? What is the privacy model when TLS/DTLS is not used? - Does the protocol expose the identity of participants to others on the network? "Res: At this point, the 3 bits" - This may be better written as perhaps: Res: In version 1 and 2 of the protocol, the 3 bits". Primitive - Please specify here what a receiver should do with an undefined primitive= value! 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? Conference ID: - Is the Conference ID randomised to provide protection to mitigate the chance of off-path data insertion attacks? Note that in section 6.2.4, symmetric port numbers (src,dst) are recommended, and hence the a random ephemeral port does not offer protection from off-path attacks in the case where TLS/DTLS is not used. Fragment Length: - What happens if the datagram length (e.g. UDP-Length) is less or more than the value specified within the BFCP? Section 6.1: CC: "if a TCP connection cannot deliver a BFCP message and times out or receives an ICMP port unreachable message mid-connection, the TCP connection SHOULD be reestablished." - I think this needs more specification. How many times will the TCP connection be retried in succession? While it seems OK for a session to be restarted because of a delivery failure, this seems like a congestion-control problem if it is unconditionally resumed with no control of the number of attempts, and no requirement to back-off after repeated failures. Section 6.2.1: Retransmission interval: "The default initial interval MUST be set to 500ms " - The protocol appears to fail systematically when the actual path RTT is greater than 500ms. The sender needs not only to expand the timer each retransmission, but needs to avoid the possibility that every message is duplicated when the path RTT is greater than 500mS. A simple solution is for the sender learn the actual RTT and increase the default timer when this is greater than 500 mS? This seems like a protocol flaw. See RFC 5405 on the need to back-off timers, based on RTT. Section 6.2.2: How does the receiving endpoint verify that the ICMP message was from the corresponding endpoint, is there any field in the protocol header that could be used to reduce the chance of off-path attacks? Section 6.2.2: This section could usefully also refer to RFC 5405. Section 6.2.3: "BFCP entities should consider the MTU size" - This isn't capitalised as "SHOULD", was that intended? I'm unclear what the intention is here, especially when discussing PMTU-D. "and MAY run MTU discovery, such as [20][21][22], for this purpose." - Presumably this is "Path" MTU Discovery. - The ID does not explain how this is done. Could it be done using dummy messages (e.g. padded out with unused options?) or some other method to probe the path? The current text simply does not explain how PMTUD or PLPMTUD is implemented, It needs to specify how to generate a "big" packet and how to handle retransmission. Congestion Control: The protocol appears to say it sends a single datagram per RTT, but actually fragmentation may result in multiple fragments per RTT. This amplifies the congestion control risk. There appears to be no limit set to the number of fragments that may be created, and each are presumably sent as a burst - and all retransmitted if there is a single loss. This could introduce a significant risk of congestion collapse, if this happens for multiple consecutive messages. Timers T1 and T2 are set to a static value by configuration. While the values suggested may be reasonable default minimum values, these two values should be increased when a path has a larger RTT to avoid the protocol replicating all data (see RFC 5405). The current specification can increase congestion for long RTT paths, and needs to be updated to reflect paths discovered to have a larger RTT. B.1.1.6. SCTP "It would be quite straight forward to specify a BFCP binding for SCTP [28], and then tunnel SCTP over UDP in the use case described in Appendix B.1. SCTP is gaining some momentum currently. There is ongoing discussion in the RTCWeb WG regarding this approach. However, this approach for tunneling over UDP was not mature enough when considered and not even fully specified." - it seems this dismisses SCTP support, yet this text appears out of date and needs to be updated to reflect RFC 6951, and possibly https://tools.ietf.org/html/draft-ietf-tsvwg-dtls-for-sctp? --_000_D11B981A407F4eckelcuciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2AF195A527D0B54F9D7FFE4E6698259D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Forwarding to list because I do not believe it made it through origina= lly.
Note, the document name in the email text should have read draft-ietf-bfcpbis-rfc4582= bis-13.txt, not draft-ietf-6man-resilient-rs-04.txt

Cheers,
Charles

From: Allison Mankin <allison.mankin@gmail.com>
Date: Monday, March 2, 2015 at 11:0= 6 AM
To: "ietf@ietf.org" <ietf@i= etf.org>, "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" <draft-= ietf-bfcpbis-rfc4582bis@tools.ietf.org>
Cc: Transport Directorate <tsv-dir@ietf.org>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, <tsv-art@ietf.org>, "bfcpbis@ietf.org" <<= a href=3D"mailto:bfcpbis@ietf.org">bfcpbis@ietf.org>
Subject: TSVDIR LC review: <draf= t-ietf-bfcpbis-rfc4582bis-13.txt> (The Binary Floor Control Protocol (BF= CP)) to Proposed Standard>

[Put into template form and forwarded for the TSVDIR reviewer, Gorry= Fairhurst, to expedite while he is traveling]

Please resolve these comments along with any other Last Call comment= s you may receive.

Document:  draft-ietf-6man-resilient-rs-04.txt Reviewer: Gorry Fairhurst
Review Date: 2015-03-01
IETF LC End Date: 2015-03-05
IESG Telechat date: ---

Summary: This draft is not ready for publication as a standards trac= k RFC.  


This document defines a control protocol that may be used over TCP o= r UDP.
The major change between this document and its predecessor RFC4528 is st= ated to be:

   Main purpose of this work was to revise the specification to support
   BFCP over an unreliable transport (Section 16.1)


The use of UDP raises a number of issues that need to be considered whe= n
used in environments that may experience congestion, long delay, or
limited capacity. Further work appears to be needed to address these
concerns. Citing RFC 5405 as normative (rather than informational) may = be
good, and some of the guidance from this BCP suggests protocol issues t= hat
should be examined and justified or amended. Notable concerns are the l= ack of
support for RTT estimation, and the way in which fragmentation is handl= ed.

There is mention of potential = support for SCTP, however the statement on
SCTP appears to need updating.=

The intro states:
"BFCP has been designed so that it can be used in low-
bandwidth environments" - there are specific low-b= andwidth
concerns when UDP is used. See below.

Section 3.4: Congestion Control
I do not understand how congestion-control is performed on the media fl= ow.
Is it the responsibility of each audio stream to independently react to=
congestion? If it is, it would be useful to state this here.

Section 5: Protocol:
"If a floor control server receives a
message with an unsupported version field value, and the extensions
in this document is supported, the receiving server MUST send an=
Error message with parameter value 12 (Unsupported Version) to indicate this. "
- What happens in the case where the receiving server does not support = the
extensions in this document? Does it silently discard?

Section 5:

What is the security model when TLS/DTLS is not used? - has the protoco= l
protection from off-path attacks, and how is this provided?

What is the privacy model when TLS/DTLS is not used?  - Does the p= rotocol
expose the identity of participants to others on the network?
"Res: At this point, the 3 bits"
- This may be better written as perhaps: Res: In version 1 and 2 of the=
protocol, the 3 bits".

Primitive
- Please specify here what a receiver should do with an undefined = primitive value!

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?

Conference ID:
- Is the Conference ID randomised to provide protection to mitigate the=
chance of off-path data insertion attacks? Note that in section 6.2.4,<= /span>
symmetric port numbers (src,dst) are recommended, and hence the a rando= m
ephemeral port does not offer protection from off-path attacks in the c= ase
where TLS/DTLS is not used.

Fragment Length:
- What happens if the datagram length (e.g. UDP-Length) is less or more=
than the value specified within the BFCP?

Section 6.1: CC:
"if a TCP
connection cannot deliver a BFCP message and times out or receives an
ICMP port unreachable message mid-connection, the TCP connection=
SHOULD be reestablished."
- I think this needs more specification. How many times will the TCP
connection be retried in succession? While it seems OK for a session to= be
restarted because of a delivery failure, this seems like a
congestion-control problem if it is unconditionally resumed with no
control of the number of attempts, and no requirement to back-off after=
repeated failures.

Section 6.2.1: Retransmission interval:
"The default initial interval MUST be set to 500ms " - The protocol appears to fail systematically  when the actual pat= h RTT is
greater than 500ms. The sender needs not only to expand the timer each<= /span>
retransmission, but needs to avoid the possibility that every message i= s
duplicated when the path RTT is greater than 500mS. A simple solution i= s
for the sender learn the actual RTT and increase the default timer when=
this is greater than 500 mS? This seems like a protocol flaw. See RFC 5= 405
on the need to back-off timers, based on RTT.

Section 6.2.2:
How does the receiving endpoint verify that the ICMP message was from t= he
corresponding endpoint, is there any field in the protocol header that<= /span>
could be used to reduce the chance of off-path attacks?

Section 6.2.2:
This section could usefully also refer to RFC 5405.

Section 6.2.3:
"BFCP entities should consider the MTU size"
- This isn't capitalised as "SHOULD", was that intended? I'm = unclear what
the intention is here, especially when discussing PMTU-D.

"and MAY run MTU discovery, such as [20][21][22], for this purpose= ."
- Presumably this is "Path" MTU Discovery.
- The ID does not explain how this is done. Could it be done using dumm= y
messages (e.g. padded out with unused options?) or some other method to=
probe the path? The current text simply does not explain how PMTUD = ; or
PLPMTUD is implemented, It needs to specify how to generate a "big= " packet
and how to handle retransmission.

Congestion Control:
The protocol appears to say it sends a single datagram per RTT, but
actually fragmentation may result in multiple fragments per RTT. This
amplifies the congestion control risk. There appears to be no limit set= to
the number of fragments that may be created, and each are presumably se= nt
as a burst - and all retransmitted if there is a single loss. This coul= d
introduce a significant risk of congestion collapse, if this happens fo= r
multiple consecutive messages.

Timers T1 and T2 are set to a static value by configuration. While the<= /span>
values suggested may be reasonable default minimum values, these two
values should be increased when a path has a larger RTT to avoid the
protocol replicating all data (see RFC 5405). The current specification=
can increase congestion for long RTT paths, and needs to be updated to<= /span>
reflect paths discovered to have a larger RTT.

B.1.1.6.  SCTP
"It would be quite straight forward to specify a BFCP binding for = SCTP
[28], and then tunnel SCTP over UDP in the use case described in=
Appendix B.1.  SCTP is gaining some momentum currently.  Ther= e is ongoing
discussion in the RTCWeb WG regarding this approach. However, this
approach for tunneling over UDP was not mature enough  when consid= ered and
not even fully specified."
- it seems this dismisses SCTP support, yet this text appears out of da= te
and needs  to be updated to reflect RFC 6951, and possibly<= br style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px"> https://tools.ietf.org/html/draft-ietf-tsvwg-dtls-for-sctp?<= /span>
 --_000_D11B981A407F4eckelcuciscocom_-- From nobody Tue Mar 3 17:02:52 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122CF1A89AC for ; Tue, 3 Mar 2015 17:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eREKX2YMheAl for ; Tue, 3 Mar 2015 17:02:44 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AD41A88E7 for ; Tue, 3 Mar 2015 17:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42690; q=dns/txt; s=iport; t=1425430964; x=1426640564; h=from:to:subject:date:message-id:mime-version; bh=z7GKEy1p85mrjBkx6vR2SGnnKKqVjhboS2fcPNYy84g=; b=CEQg58Oq5ZyXYLclPSZZDv6bEVepoy6S7d4/ll2pPiNVdZNo01YMjgy7 vSrx+rR50EaQllrDqfcCiS+y4OtTlw33V3kPdw2+RJuxHOOvj5kH/GMFh A1UuUi9yxDBnuv6Ghk5teFIY5XJ3J7bNxOXAR/IHqcF0jK88ex2OdeAeD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DnBgB/WPZU/5FdJa1RCYI/Q1JPD7tNhW8BCYUnSQKBJ00BAQEBAQF8hA8BAgRoBB8BCBEDAQIhAQIEKBEUCAEKBAESCRKIAAMRDdEnDYUeAQEBAQYBAQEBHosSgkSBSAcDAQUCAT4NEYInTYExBY95g2CEIYFIgRqDIoJThkWGDCOCAhwUgTxvAYEBAR8ifwEBAQ X-IronPort-AV: E=Sophos;i="5.09,684,1418083200"; d="scan'208,217";a="400654007" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 04 Mar 2015 01:02:43 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2412hav001317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Mar 2015 01:02:43 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.45]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 19:02:43 -0600 From: "Charles Eckel (eckelcu)" To: "Charles Eckel (eckelcu)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] FW: TSVDIR LC review: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard> Thread-Index: AQHQVhbqN9JjpmyF7kqz2MEFVpoyog== Date: Wed, 4 Mar 2015 01:02:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.22.181] Content-Type: multipart/alternative; boundary="_000_D11B996B40807eckelcuciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bfcpbis] FW: TSVDIR LC review: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard> X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 01:02:49 -0000 --_000_D11B996B40807eckelcuciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, found it, http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00= 362.html From: Charles Eckel > Date: Tuesday, March 3, 2015 at 6:58 PM To: "bfcpbis@ietf.org" > Subject: [bfcpbis] FW: TSVDIR LC review: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard> Forwarding to list because I do not believe it made it through originally. Note, the document name in the email text should have read draft-ietf-bfcpb= is-rfc4582bis-13.txt, not draft-ietf-6man-resilient-rs-04.txt Cheers, Charles From: Allison Mankin > Date: Monday, March 2, 2015 at 11:06 AM To: "ietf@ietf.org" >, "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" > Cc: Transport Directorate >, "gor= ry@erg.abdn.ac.uk" >, >, "bfc= pbis@ietf.org" > Subject: TSVDIR LC review: (The Bina= ry Floor Control Protocol (BFCP)) to Proposed Standard> [Put into template form and forwarded for the TSVDIR reviewer, Gorry Fairhu= rst, to expedite while he is traveling] Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-6man-resilient-rs-04.txt Reviewer: Gorry Fairhurst Review Date: 2015-03-01 IETF LC End Date: 2015-03-05 IESG Telechat date: --- Summary: This draft is not ready for publication as a standards track RFC. This document defines a control protocol that may be used over TCP or UDP. The major change between this document and its predecessor RFC4528 is state= d to be: Main purpose of this work was to revise the specification to support BFCP over an unreliable transport (Section 16.1) The use of UDP raises a number of issues that need to be considered when used in environments that may experience congestion, long delay, or limited capacity. Further work appears to be needed to address these concerns. Citing RFC 5405 as normative (rather than informational) may be good, and some of the guidance from this BCP suggests protocol issues that should be examined and justified or amended. Notable concerns are the lack = of support for RTT estimation, and the way in which fragmentation is handled. There is mention of potential support for SCTP, however the statement on SCTP appears to need updating. The intro states: "BFCP has been designed so that it can be used in low- bandwidth environments" - there are specific low-bandwidth concerns when UDP is used. See below. Section 3.4: Congestion Control I do not understand how congestion-control is performed on the media flow. Is it the responsibility of each audio stream to independently react to congestion? If it is, it would be useful to state this here. Section 5: Protocol: "If a floor control server receives a message with an unsupported version field value, and the extensions in this document is supported, the receiving server MUST send an Error message with parameter value 12 (Unsupported Version) to indicate this. " - What happens in the case where the receiving server does not support the extensions in this document? Does it silently discard? 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? What is the privacy model when TLS/DTLS is not used? - Does the protocol expose the identity of participants to others on the network? "Res: At this point, the 3 bits" - This may be better written as perhaps: Res: In version 1 and 2 of the protocol, the 3 bits". Primitive - Please specify here what a receiver should do with an undefined primitive= value! 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? Conference ID: - Is the Conference ID randomised to provide protection to mitigate the chance of off-path data insertion attacks? Note that in section 6.2.4, symmetric port numbers (src,dst) are recommended, and hence the a random ephemeral port does not offer protection from off-path attacks in the case where TLS/DTLS is not used. Fragment Length: - What happens if the datagram length (e.g. UDP-Length) is less or more than the value specified within the BFCP? Section 6.1: CC: "if a TCP connection cannot deliver a BFCP message and times out or receives an ICMP port unreachable message mid-connection, the TCP connection SHOULD be reestablished." - I think this needs more specification. How many times will the TCP connection be retried in succession? While it seems OK for a session to be restarted because of a delivery failure, this seems like a congestion-control problem if it is unconditionally resumed with no control of the number of attempts, and no requirement to back-off after repeated failures. Section 6.2.1: Retransmission interval: "The default initial interval MUST be set to 500ms " - The protocol appears to fail systematically when the actual path RTT is greater than 500ms. The sender needs not only to expand the timer each retransmission, but needs to avoid the possibility that every message is duplicated when the path RTT is greater than 500mS. A simple solution is for the sender learn the actual RTT and increase the default timer when this is greater than 500 mS? This seems like a protocol flaw. See RFC 5405 on the need to back-off timers, based on RTT. Section 6.2.2: How does the receiving endpoint verify that the ICMP message was from the corresponding endpoint, is there any field in the protocol header that could be used to reduce the chance of off-path attacks? Section 6.2.2: This section could usefully also refer to RFC 5405. Section 6.2.3: "BFCP entities should consider the MTU size" - This isn't capitalised as "SHOULD", was that intended? I'm unclear what the intention is here, especially when discussing PMTU-D. "and MAY run MTU discovery, such as [20][21][22], for this purpose." - Presumably this is "Path" MTU Discovery. - The ID does not explain how this is done. Could it be done using dummy messages (e.g. padded out with unused options?) or some other method to probe the path? The current text simply does not explain how PMTUD or PLPMTUD is implemented, It needs to specify how to generate a "big" packet and how to handle retransmission. Congestion Control: The protocol appears to say it sends a single datagram per RTT, but actually fragmentation may result in multiple fragments per RTT. This amplifies the congestion control risk. There appears to be no limit set to the number of fragments that may be created, and each are presumably sent as a burst - and all retransmitted if there is a single loss. This could introduce a significant risk of congestion collapse, if this happens for multiple consecutive messages. Timers T1 and T2 are set to a static value by configuration. While the values suggested may be reasonable default minimum values, these two values should be increased when a path has a larger RTT to avoid the protocol replicating all data (see RFC 5405). The current specification can increase congestion for long RTT paths, and needs to be updated to reflect paths discovered to have a larger RTT. B.1.1.6. SCTP "It would be quite straight forward to specify a BFCP binding for SCTP [28], and then tunnel SCTP over UDP in the use case described in Appendix B.1. SCTP is gaining some momentum currently. There is ongoing discussion in the RTCWeb WG regarding this approach. However, this approach for tunneling over UDP was not mature enough when considered and not even fully specified." - it seems this dismisses SCTP support, yet this text appears out of date and needs to be updated to reflect RFC 6951, and possibly https://tools.ietf.org/html/draft-ietf-tsvwg-dtls-for-sctp? --_000_D11B996B40807eckelcuciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

From: Charles Eckel <eckelcu@cisco.com>
Date: Tuesday, March 3, 2015 at 6:5= 8 PM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] FW: TSVDIR LC re= view: <draft-ietf-bfcpbis-rfc4582bis-13.txt> (The Binary Floor Contro= l Protocol (BFCP)) to Proposed Standard>

Forwarding to list because I do not believe it made it through origina= lly.
Note, the document name in the email text should have read draft-ietf-bfcpbis-rfc4582= bis-13.txt, not draft-ietf-6man-resilient-rs-04.txt

Cheers,
Charles

From: Allison Mankin <allison.mankin@gmail.com>
Date: Monday, March 2, 2015 at 11:0= 6 AM
To: "ietf@ietf.org" <ietf@i= etf.org>, "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" <draft-= ietf-bfcpbis-rfc4582bis@tools.ietf.org>
Cc: Transport Directorate <tsv-dir@ietf.org>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, <tsv-art@ietf.org>, "bfcpbis@ietf.org" <<= a href=3D"mailto:bfcpbis@ietf.org">bfcpbis@ietf.org>
Subject: TSVDIR LC review: <draf= t-ietf-bfcpbis-rfc4582bis-13.txt> (The Binary Floor Control Protocol (BF= CP)) to Proposed Standard>

[Put into template form and forwarded for the TSVDIR reviewer, Gorry= Fairhurst, to expedite while he is traveling]

Please resolve these comments along with any other Last Call comment= s you may receive.

Document:  draft-ietf-6man-resilient-rs-04.txt Reviewer: Gorry Fairhurst
Review Date: 2015-03-01
IETF LC End Date: 2015-03-05
IESG Telechat date: ---

Summary: This draft is not ready for publication as a standards trac= k RFC.  


This document defines a control protocol that may be used over TCP o= r UDP.
The major change between this document and its predecessor RFC4528 is st= ated to be:

   Main purpose of this work was to revise the specification to support
   BFCP over an unreliable transport (Section 16.1)


The use of UDP raises a number of issues that need to be considered whe= n
used in environments that may experience congestion, long delay, or
limited capacity. Further work appears to be needed to address these
concerns. Citing RFC 5405 as normative (rather than informational) may = be
good, and some of the guidance from this BCP suggests protocol issues t= hat
should be examined and justified or amended. Notable concerns are the l= ack of
support for RTT estimation, and the way in which fragmentation is handl= ed.

There is mention of potential = support for SCTP, however the statement on
SCTP appears to need updating.=

The intro states:
"BFCP has been designed so that it can be used in low-
bandwidth environments" - there are specific low-b= andwidth
concerns when UDP is used. See below.

Section 3.4: Congestion Control
I do not understand how congestion-control is performed on the media fl= ow.
Is it the responsibility of each audio stream to independently react to=
congestion? If it is, it would be useful to state this here.

Section 5: Protocol:
"If a floor control server receives a
message with an unsupported version field value, and the extensions
in this document is supported, the receiving server MUST send an=
Error message with parameter value 12 (Unsupported Version) to indicate this. "
- What happens in the case where the receiving server does not support = the
extensions in this document? Does it silently discard?

Section 5:

What is the security model when TLS/DTLS is not used? - has the protoco= l
protection from off-path attacks, and how is this provided?

What is the privacy model when TLS/DTLS is not used?  - Does the p= rotocol
expose the identity of participants to others on the network?
"Res: At this point, the 3 bits"
- This may be better written as perhaps: Res: In version 1 and 2 of the=
protocol, the 3 bits".

Primitive
- Please specify here what a receiver should do with an undefined = primitive value!

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?

Conference ID:
- Is the Conference ID randomised to provide protection to mitigate the=
chance of off-path data insertion attacks? Note that in section 6.2.4,<= /span>
symmetric port numbers (src,dst) are recommended, and hence the a rando= m
ephemeral port does not offer protection from off-path attacks in the c= ase
where TLS/DTLS is not used.

Fragment Length:
- What happens if the datagram length (e.g. UDP-Length) is less or more=
than the value specified within the BFCP?

Section 6.1: CC:
"if a TCP
connection cannot deliver a BFCP message and times out or receives an
ICMP port unreachable message mid-connection, the TCP connection=
SHOULD be reestablished."
- I think this needs more specification. How many times will the TCP
connection be retried in succession? While it seems OK for a session to= be
restarted because of a delivery failure, this seems like a
congestion-control problem if it is unconditionally resumed with no
control of the number of attempts, and no requirement to back-off after=
repeated failures.

Section 6.2.1: Retransmission interval:
"The default initial interval MUST be set to 500ms " - The protocol appears to fail systematically  when the actual pat= h RTT is
greater than 500ms. The sender needs not only to expand the timer each<= /span>
retransmission, but needs to avoid the possibility that every message i= s
duplicated when the path RTT is greater than 500mS. A simple solution i= s
for the sender learn the actual RTT and increase the default timer when=
this is greater than 500 mS? This seems like a protocol flaw. See RFC 5= 405
on the need to back-off timers, based on RTT.

Section 6.2.2:
How does the receiving endpoint verify that the ICMP message was from t= he
corresponding endpoint, is there any field in the protocol header that<= /span>
could be used to reduce the chance of off-path attacks?

Section 6.2.2:
This section could usefully also refer to RFC 5405.

Section 6.2.3:
"BFCP entities should consider the MTU size"
- This isn't capitalised as "SHOULD", was that intended? I'm = unclear what
the intention is here, especially when discussing PMTU-D.

"and MAY run MTU discovery, such as [20][21][22], for this purpose= ."
- Presumably this is "Path" MTU Discovery.
- The ID does not explain how this is done. Could it be done using dumm= y
messages (e.g. padded out with unused options?) or some other method to=
probe the path? The current text simply does not explain how PMTUD = ; or
PLPMTUD is implemented, It needs to specify how to generate a "big= " packet
and how to handle retransmission.

Congestion Control:
The protocol appears to say it sends a single datagram per RTT, but
actually fragmentation may result in multiple fragments per RTT. This
amplifies the congestion control risk. There appears to be no limit set= to
the number of fragments that may be created, and each are presumably se= nt
as a burst - and all retransmitted if there is a single loss. This coul= d
introduce a significant risk of congestion collapse, if this happens fo= r
multiple consecutive messages.

Timers T1 and T2 are set to a static value by configuration. While the<= /span>
values suggested may be reasonable default minimum values, these two
values should be increased when a path has a larger RTT to avoid the
protocol replicating all data (see RFC 5405). The current specification=
can increase congestion for long RTT paths, and needs to be updated to<= /span>
reflect paths discovered to have a larger RTT.

B.1.1.6.  SCTP
"It would be quite straight forward to specify a BFCP binding for = SCTP
[28], and then tunnel SCTP over UDP in the use case described in=
Appendix B.1.  SCTP is gaining some momentum currently.  Ther= e is ongoing
discussion in the RTCWeb WG regarding this approach. However, this
approach for tunneling over UDP was not mature enough  when consid= ered and
not even fully specified."
- it seems this dismisses SCTP support, yet this text appears out of da= te
and needs  to be updated to reflect RFC 6951, and possibly<= br style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px"> https://tools.ietf.org/html/draft-ietf-tsvwg-dtls-for-sctp?<= /span>
 --_000_D11B996B40807eckelcuciscocom_-- From nobody Wed Mar 4 20:38:30 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30091A901E; Wed, 4 Mar 2015 20:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlMut7rYVzPl; Wed, 4 Mar 2015 20:38:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8331A8F41; Wed, 4 Mar 2015 20:38:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305043826.4994.75386.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 20:38:26 -0800 Archived-At: Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, bfcpbis-chairs@ietf.org Subject: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 04:38:27 -0000 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. - 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? From nobody Wed Mar 4 20:38:31 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D6BB61AD1DB; Wed, 4 Mar 2015 20:38:27 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30091A901E; Wed, 4 Mar 2015 20:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlMut7rYVzPl; Wed, 4 Mar 2015 20:38:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8331A8F41; Wed, 4 Mar 2015 20:38:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305043826.4994.75386.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 20:38:26 -0800 Archived-At: Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, bfcpbis-chairs@ietf.org Subject: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 04:38:28 -0000 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. - 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? From nobody Thu Mar 5 00:09:30 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2390A1B2A45; Thu, 5 Mar 2015 00:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je3X3R9xeXEr; Thu, 5 Mar 2015 00:09:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 518B91B2A38; Thu, 5 Mar 2015 00:09:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305080927.22286.18426.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 00:09:27 -0800 Archived-At: Cc: iesg-secretary@ietf.org Subject: [bfcpbis] Last Call Expired: X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 08:09:29 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Mar 5 00:09:33 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 455731B2A4A; Thu, 5 Mar 2015 00:09:29 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2390A1B2A45; Thu, 5 Mar 2015 00:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je3X3R9xeXEr; Thu, 5 Mar 2015 00:09:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 518B91B2A38; Thu, 5 Mar 2015 00:09:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305080927.22286.18426.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 00:09:27 -0800 Archived-At: Cc: iesg-secretary@ietf.org Subject: [bfcpbis] Last Call Expired: X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 08:09:29 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Mar 5 04:01:44 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DDA1B2C3A; Thu, 5 Mar 2015 04:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYd0pdP5nJBO; Thu, 5 Mar 2015 04:01:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A78471A8773; Thu, 5 Mar 2015 04:01:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305120139.5359.3899.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 04:01:39 -0800 Archived-At: Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, suresh.krishnan@ericsson.com, bfcpbis-chairs@ietf.org Subject: [bfcpbis] Jari Arkko's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:01:43 -0000 Jari Arkko 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: ---------------------------------------------------------------------- Thanks for the hard work on this protocol. I have some comments, based on a review by Suresh Krishnan, that I think should be addressed before final approval of the document. First, Section 5.1 should be clear that when used over a reliable transport, not only should the F flag be ignore but that the fragment fields (last four bytes) are not in the packet. Second, Section 6.2.3 should be clear that the header accompanies all fragments. As a result, the current formula for calculating the number of fragments is probably wrong. This too should be updated. From nobody Thu Mar 5 04:01:51 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9E91C1A8773; Thu, 5 Mar 2015 04:01:43 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DDA1B2C3A; Thu, 5 Mar 2015 04:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYd0pdP5nJBO; Thu, 5 Mar 2015 04:01:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A78471A8773; Thu, 5 Mar 2015 04:01:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305120139.5359.3899.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 04:01:39 -0800 Archived-At: Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, suresh.krishnan@ericsson.com, bfcpbis-chairs@ietf.org Subject: [bfcpbis] Jari Arkko's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:01:43 -0000 Jari Arkko 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: ---------------------------------------------------------------------- Thanks for the hard work on this protocol. I have some comments, based on a review by Suresh Krishnan, that I think should be addressed before final approval of the document. First, Section 5.1 should be clear that when used over a reliable transport, not only should the F flag be ignore but that the fragment fields (last four bytes) are not in the packet. Second, Section 6.2.3 should be clear that the header accompanies all fragments. As a result, the current formula for calculating the number of fragments is probably wrong. This too should be updated. From nobody Thu Mar 5 04:16:16 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73FF1B2B14; Thu, 5 Mar 2015 04:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFTQl7PrQOeU; Thu, 5 Mar 2015 04:16:13 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B83F1A8773; Thu, 5 Mar 2015 04:16:08 -0800 (PST) X-AuditID: c1b4fb30-f79c86d000000fc0-2f-54f8490611ad Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 98.35.04032.60948F45; Thu, 5 Mar 2015 13:16:07 +0100 (CET) Received: from [131.160.126.7] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.210.2; Thu, 5 Mar 2015 13:16:06 +0100 Message-ID: <54F84906.5010201@ericsson.com> Date: Thu, 5 Mar 2015 14:16:06 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jari Arkko , The IESG References: <20150305120139.5359.3899.idtracker@ietfa.amsl.com> In-Reply-To: <20150305120139.5359.3899.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjS67548Qg41X+Sw+LvzGYvFv3VEm iyNnf7NYzPgzkdlixr4VbBaf9+9ndmDz2DnrLrvHkiU/mTy2LpnOFsAcxWWTkpqTWZZapG+X wJXxrWMHa8Fynoqpvy8wNzD+4exi5OSQEDCR+No8lx3CFpO4cG89WxcjF4eQwBFGiWnTf0M5 qxgl+r5cYASp4hXQltg8fwOYzSKgIvHw+GZmEJtNwEJiy637LCC2qECUxOzzD1gh6gUlTs58 AhYXEbCX+LD7IBPIUGaBhYwS33/tAysSFgiXOHZyEdggIaCiRQdugdmcAg4SszpeAtVwADVo SqzfpQ8SZhaQl9j+dg5UubbE8mctLBMYBWchWTcLoWMWko4FjMyrGEWLU4uTctONjPRSizKT i4vz8/TyUks2MQID/OCW3wY7GF8+dzzEKMDBqMTDu+HY9xAh1sSy4srcQ4zSHCxK4rx2xodC hATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTB2WfeZSH323/pq/7YVJ9cfXPcy5P7KfSuPfpeS O/NlSqepTEbLPoOH5UZvBAsKjBcVum69UJsl6/el41rnLNbqXFXX8LYPp5jOfPxusfjN2bev W5XfG8Q2bnQWlBRgXvw37+r65a2xMfsS93EqBb5251okfdy8MWDWmqf9D69o5EztTfFR//pS iaU4I9FQi7moOBEApwMGA1ECAAA= Archived-At: Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, suresh.krishnan@ericsson.com, bfcpbis-chairs@ietf.org Subject: Re: [bfcpbis] Jari Arkko's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:16:14 -0000 Jari, Suresh, thanks for your comments. Tom is currently editing this draft. He will get back to you with a response shortly. Cheers, Gonzalo On 05/03/2015 2:01 PM, Jari Arkko wrote: > Jari Arkko 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: > ---------------------------------------------------------------------- > > Thanks for the hard work on this protocol. I have some comments, based on > a review by Suresh Krishnan, that I think should be addressed before > final approval of the document. > > First, Section 5.1 should be clear that when used over a reliable > transport, not only should the F flag be ignore but that the fragment > fields (last four bytes) are not in the packet. > > Second, Section 6.2.3 should be clear that the header accompanies all > fragments. As a result, the current formula for calculating the number of > fragments is probably wrong. This too should be updated. > > > > From nobody Thu Mar 5 04:16:20 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E908F1B2C3D; Thu, 5 Mar 2015 04:16:14 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73FF1B2B14; Thu, 5 Mar 2015 04:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFTQl7PrQOeU; Thu, 5 Mar 2015 04:16:13 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B83F1A8773; Thu, 5 Mar 2015 04:16:08 -0800 (PST) X-AuditID: c1b4fb30-f79c86d000000fc0-2f-54f8490611ad Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 98.35.04032.60948F45; Thu, 5 Mar 2015 13:16:07 +0100 (CET) Received: from [131.160.126.7] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.210.2; Thu, 5 Mar 2015 13:16:06 +0100 Message-ID: <54F84906.5010201@ericsson.com> Date: Thu, 5 Mar 2015 14:16:06 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jari Arkko , The IESG References: <20150305120139.5359.3899.idtracker@ietfa.amsl.com> In-Reply-To: <20150305120139.5359.3899.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjS67548Qg41X+Sw+LvzGYvFv3VEm iyNnf7NYzPgzkdlixr4VbBaf9+9ndmDz2DnrLrvHkiU/mTy2LpnOFsAcxWWTkpqTWZZapG+X wJXxrWMHa8Fynoqpvy8wNzD+4exi5OSQEDCR+No8lx3CFpO4cG89WxcjF4eQwBFGiWnTf0M5 qxgl+r5cYASp4hXQltg8fwOYzSKgIvHw+GZmEJtNwEJiy637LCC2qECUxOzzD1gh6gUlTs58 AhYXEbCX+LD7IBPIUGaBhYwS33/tAysSFgiXOHZyEdggIaCiRQdugdmcAg4SszpeAtVwADVo SqzfpQ8SZhaQl9j+dg5UubbE8mctLBMYBWchWTcLoWMWko4FjMyrGEWLU4uTctONjPRSizKT i4vz8/TyUks2MQID/OCW3wY7GF8+dzzEKMDBqMTDu+HY9xAh1sSy4srcQ4zSHCxK4rx2xodC hATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTB2WfeZSH323/pq/7YVJ9cfXPcy5P7KfSuPfpeS O/NlSqepTEbLPoOH5UZvBAsKjBcVum69UJsl6/el41rnLNbqXFXX8LYPp5jOfPxusfjN2bev W5XfG8Q2bnQWlBRgXvw37+r65a2xMfsS93EqBb5251okfdy8MWDWmqf9D69o5EztTfFR//pS iaU4I9FQi7moOBEApwMGA1ECAAA= Archived-At: Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, suresh.krishnan@ericsson.com, bfcpbis-chairs@ietf.org Subject: Re: [bfcpbis] Jari Arkko's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:16:15 -0000 Jari, Suresh, thanks for your comments. Tom is currently editing this draft. He will get back to you with a response shortly. Cheers, Gonzalo On 05/03/2015 2:01 PM, Jari Arkko wrote: > Jari Arkko 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: > ---------------------------------------------------------------------- > > Thanks for the hard work on this protocol. I have some comments, based on > a review by Suresh Krishnan, that I think should be addressed before > final approval of the document. > > First, Section 5.1 should be clear that when used over a reliable > transport, not only should the F flag be ignore but that the fragment > fields (last four bytes) are not in the packet. > > Second, Section 6.2.3 should be clear that the header accompanies all > fragments. As a result, the current formula for calculating the number of > fragments is probably wrong. This too should be updated. > > > > From nobody Thu Mar 5 06:46:35 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32F41A000F; Thu, 5 Mar 2015 06:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxXnGgbtT2ft; Thu, 5 Mar 2015 06:46:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9222F1A0006; Thu, 5 Mar 2015 06:46:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305144631.20916.24150.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 06:46:31 -0800 Archived-At: Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, bfcpbis-chairs@ietf.org Subject: [bfcpbis] Barry Leiba's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 14:46:33 -0000 Barry Leiba 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: ---------------------------------------------------------------------- The IANA Considerations are a bit confusing, as they appear to ask IANA to do things that were already done long ago. I understand that you want to leave the main text of the IANA Considerations intact, for posterity, and you've put in some "Editorial note" things. Maybe the best way to do this is to (1) change "Editorial note" to "IANA note" or "Note to IANA" throughout, (2) change the first IANA note (in the base Section 15) to clearly state that all *changes* that IANA is being asked to make are spelled out in "IANA note" items in the appropriate places, and (3) make sure that item 2 is true. And you do need to respond to Pearl Liang's IANA review from 2 March, and answer her questions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks VERY much for leaving it so that a diff with 4582 was still useful for review. That helped a great deal. It's a little nothing, so ignore this if you like, but you consistently use "MUST" throughout the document, except for one "SHALL" in Section 8.3.3. If it were me, I'd be consistent and use "MUST" there as well, to avoid any question of why that one is different. Thanks for making the editorial changes to the ABNF; I do prefer "*(X)" to "*[X]". On the other hand, I actually prefer "*X" to both of those: there's no need to use parentheses around a single production name. So, for example, this: BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) [USER-DISPLAY-NAME] [USER-URI] *(EXTENSION-ATTRIBUTE) Is the same as this: BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER [USER-DISPLAY-NAME] [USER-URI] *EXTENSION-ATTRIBUTE No harm either way, so leave it as is if you really like it, but... why the parentheses, especially as long as you're changing them anyway? From nobody Thu Mar 5 06:46:37 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C195B1A001D; Thu, 5 Mar 2015 06:46:33 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32F41A000F; Thu, 5 Mar 2015 06:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxXnGgbtT2ft; Thu, 5 Mar 2015 06:46:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9222F1A0006; Thu, 5 Mar 2015 06:46:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305144631.20916.24150.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 06:46:31 -0800 Archived-At: Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, bfcpbis-chairs@ietf.org Subject: [bfcpbis] Barry Leiba's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 14:46:33 -0000 Barry Leiba 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: ---------------------------------------------------------------------- The IANA Considerations are a bit confusing, as they appear to ask IANA to do things that were already done long ago. I understand that you want to leave the main text of the IANA Considerations intact, for posterity, and you've put in some "Editorial note" things. Maybe the best way to do this is to (1) change "Editorial note" to "IANA note" or "Note to IANA" throughout, (2) change the first IANA note (in the base Section 15) to clearly state that all *changes* that IANA is being asked to make are spelled out in "IANA note" items in the appropriate places, and (3) make sure that item 2 is true. And you do need to respond to Pearl Liang's IANA review from 2 March, and answer her questions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks VERY much for leaving it so that a diff with 4582 was still useful for review. That helped a great deal. It's a little nothing, so ignore this if you like, but you consistently use "MUST" throughout the document, except for one "SHALL" in Section 8.3.3. If it were me, I'd be consistent and use "MUST" there as well, to avoid any question of why that one is different. Thanks for making the editorial changes to the ABNF; I do prefer "*(X)" to "*[X]". On the other hand, I actually prefer "*X" to both of those: there's no need to use parentheses around a single production name. So, for example, this: BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) [USER-DISPLAY-NAME] [USER-URI] *(EXTENSION-ATTRIBUTE) Is the same as this: BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER [USER-DISPLAY-NAME] [USER-URI] *EXTENSION-ATTRIBUTE No harm either way, so leave it as is if you really like it, but... why the parentheses, especially as long as you're changing them anyway? From nobody Thu Mar 5 07:29:25 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0C91A03A1; Thu, 5 Mar 2015 07:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBk4mt25-xbb; Thu, 5 Mar 2015 07:29:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B0F1A011B; Thu, 5 Mar 2015 07:28:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305152844.22120.78057.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 07:28:44 -0800 Archived-At: Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, bfcpbis-chairs@ietf.org Subject: [bfcpbis] Stephen Farrell's No Objection on draft-ietf-bfcpbis-rfc4582bis-13: (with COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 15:29:24 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-bfcpbis-rfc4582bis-13: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 7: As in other cases, this might be better to refer to the generic UTA work rather than have it's own list of preferred ciphersuites. - I wondered why you'd not just moved all the way to make TLS mutual-auth mandatory to use for this. From nobody Thu Mar 5 07:29:28 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9C7BF1A011B; Thu, 5 Mar 2015 07:29:24 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0C91A03A1; Thu, 5 Mar 2015 07:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBk4mt25-xbb; Thu, 5 Mar 2015 07:29:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B0F1A011B; Thu, 5 Mar 2015 07:28:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305152844.22120.78057.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 07:28:44 -0800 Archived-At: Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, bfcpbis-chairs@ietf.org Subject: [bfcpbis] Stephen Farrell's No Objection on draft-ietf-bfcpbis-rfc4582bis-13: (with COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 15:29:24 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-bfcpbis-rfc4582bis-13: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 7: As in other cases, this might be better to refer to the generic UTA work rather than have it's own list of preferred ciphersuites. - I wondered why you'd not just moved all the way to make TLS mutual-auth mandatory to use for this. From nobody Thu Mar 5 08:14:19 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78D01A00B1; Thu, 5 Mar 2015 07:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPNAkn3pcOQQ; Thu, 5 Mar 2015 07:01:23 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD531A004D; Thu, 5 Mar 2015 07:01:19 -0800 (PST) Received: by lbjf15 with SMTP id f15so23861422lbj.2; Thu, 05 Mar 2015 07:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0uiubY916SQVjtTr7WMw6EUR+lV635y86/S8NqokJIk=; b=H1Xjjtrx1jg6yYykyjFzVqOIqnbMH2aNKK3bbWRMOSG5rW5BA39GjhLJlLQlSlVD9w cpKev935jMBuTMATjulayfBjNiI3o6Iryc7APmnljsAQXcL+XJeeS2esfbyDpgnmr7La VfRW5gSPGfAd/h+/nPxnCqQRICXwBLo3d/bRJpCZuc2Oe4q/+iNY4tJyid7yPD1ALJKd xou2SDMxr4RVvZhj6VNQMgO/9J8Ov50y149bUgDIHcEkPubTe6kHRCheJKh8C8aryXMv ZAKWeiRicEhvWgchwKMKG9x6dL+6+Br7JlNROYHxm8y4Pg+A5SUmiVtpmGwW3JlOYb10 Aosw== MIME-Version: 1.0 X-Received: by 10.152.87.199 with SMTP id ba7mr3028468lab.75.1425567677623; Thu, 05 Mar 2015 07:01:17 -0800 (PST) Received: by 10.112.167.101 with HTTP; Thu, 5 Mar 2015 07:01:17 -0800 (PST) In-Reply-To: <20150305043826.4994.75386.idtracker@ietfa.amsl.com> References: <20150305043826.4994.75386.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 10:01:17 -0500 Message-ID: From: Kathleen Moriarty To: Spencer Dawkins Content-Type: multipart/alternative; boundary=001a11c34e460735f805108bd749 Archived-At: X-Mailman-Approved-At: Thu, 05 Mar 2015 08:14:17 -0800 Cc: bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, Mary Barnes , The IESG , bfcpbis-chairs@ietf.org Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 15:01:26 -0000 --001a11c34e460735f805108bd749 Content-Type: text/plain; charset=UTF-8 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 < spencerdawkins.ietf@gmail.com> 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 --001a11c34e460735f805108bd749 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 <spencerdawkins.ietf@gmail.= com> wrote:
Spencer Dawkins has entered t= he 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-crit= eria.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-rfc458= 2bis/



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

For the moment, I'm balloting a process Discuss, because I'm not se= eing a
response to Gorry Fairhurst's TSV-DIR review sent on March 2, at
https://www.ietf.org/mail-archive/web/ietf/current/msg9= 2156.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 versio= n
number, but in this draft, version 1 means "reliable transport" a= nd
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=C2=
=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0mechanisms.=C2=A0

This covers MTI, we usually don't get into MTU.=C2= =A0 Are you asking that the properties required for other secure transport = alternatives be listed?=C2=A0 If someone doesn't want to turn on encryp= tion and have that session established securely, they could have a really &= #39;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 p= revent fragmentation overlap attacks, so I'll add a discuss as I think = it's important to have this stated.

Thanks,
Kathleen=C2=A0



-- <= br>

Best regards,
Kathleen
--001a11c34e460735f805108bd749-- From nobody Thu Mar 5 08:14:20 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 103151A004D; Thu, 5 Mar 2015 07:01:26 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78D01A00B1; Thu, 5 Mar 2015 07:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPNAkn3pcOQQ; Thu, 5 Mar 2015 07:01:23 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD531A004D; Thu, 5 Mar 2015 07:01:19 -0800 (PST) Received: by lbjf15 with SMTP id f15so23861422lbj.2; Thu, 05 Mar 2015 07:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0uiubY916SQVjtTr7WMw6EUR+lV635y86/S8NqokJIk=; b=H1Xjjtrx1jg6yYykyjFzVqOIqnbMH2aNKK3bbWRMOSG5rW5BA39GjhLJlLQlSlVD9w cpKev935jMBuTMATjulayfBjNiI3o6Iryc7APmnljsAQXcL+XJeeS2esfbyDpgnmr7La VfRW5gSPGfAd/h+/nPxnCqQRICXwBLo3d/bRJpCZuc2Oe4q/+iNY4tJyid7yPD1ALJKd xou2SDMxr4RVvZhj6VNQMgO/9J8Ov50y149bUgDIHcEkPubTe6kHRCheJKh8C8aryXMv ZAKWeiRicEhvWgchwKMKG9x6dL+6+Br7JlNROYHxm8y4Pg+A5SUmiVtpmGwW3JlOYb10 Aosw== MIME-Version: 1.0 X-Received: by 10.152.87.199 with SMTP id ba7mr3028468lab.75.1425567677623; Thu, 05 Mar 2015 07:01:17 -0800 (PST) Received: by 10.112.167.101 with HTTP; Thu, 5 Mar 2015 07:01:17 -0800 (PST) In-Reply-To: <20150305043826.4994.75386.idtracker@ietfa.amsl.com> References: <20150305043826.4994.75386.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 10:01:17 -0500 Message-ID: From: Kathleen Moriarty To: Spencer Dawkins Content-Type: multipart/alternative; boundary=001a11c34e460735f805108bd749 Archived-At: X-Mailman-Approved-At: Thu, 05 Mar 2015 08:14:17 -0800 Cc: bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, Mary Barnes , The IESG , bfcpbis-chairs@ietf.org Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 15:01:26 -0000 --001a11c34e460735f805108bd749 Content-Type: text/plain; charset=UTF-8 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 < spencerdawkins.ietf@gmail.com> 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 --001a11c34e460735f805108bd749 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 <spencerdawkins.ietf@gmail.= com> wrote:
Spencer Dawkins has entered t= he 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-crit= eria.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-rfc458= 2bis/



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

For the moment, I'm balloting a process Discuss, because I'm not se= eing a
response to Gorry Fairhurst's TSV-DIR review sent on March 2, at
https://www.ietf.org/mail-archive/web/ietf/current/msg9= 2156.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 versio= n
number, but in this draft, version 1 means "reliable transport" a= nd
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=C2=
=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0mechanisms.=C2=A0

This covers MTI, we usually don't get into MTU.=C2= =A0 Are you asking that the properties required for other secure transport = alternatives be listed?=C2=A0 If someone doesn't want to turn on encryp= tion and have that session established securely, they could have a really &= #39;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 p= revent fragmentation overlap attacks, so I'll add a discuss as I think = it's important to have this stated.

Thanks,
Kathleen=C2=A0



-- <= br>

Best regards,
Kathleen
--001a11c34e460735f805108bd749-- From nobody Thu Mar 5 08:14:21 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC861A0381; Thu, 5 Mar 2015 07:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTUIt-Z-Dogc; Thu, 5 Mar 2015 07:24:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 971111A1A8D; Thu, 5 Mar 2015 07:22:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305152202.28872.54032.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 07:22:02 -0800 Archived-At: X-Mailman-Approved-At: Thu, 05 Mar 2015 08:14:17 -0800 Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, bfcpbis-chairs@ietf.org Subject: [bfcpbis] Kathleen Moriarty's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 15:24:26 -0000 Kathleen Moriarty 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: ---------------------------------------------------------------------- Thanks for your work on this draft, it was very well written which is much appreciated. I just have one item I'd like to discuss that should be very easy to resolve. This should be considered with Spencer's question on what happens when the fragments are larger or smaller than the path MTU. It's important to state this to prevent fragmentation overlap attacks (unless you can explain why we don't need to worry about that). In the second sentence on page 42, adding the ending clause may be helpful: The size of each of these N messages MUST be smaller than the path MTU to help prevent fragmentation overlap attacks. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Spencer asked what happens when TLS/DTLS is not used, so perhaps rewording of the intro to the security considerations section would help to clear up his point. TLS/DTLS is the MTI with flexibility left in to support some other undefined mechanism to secure the channel. Since no MTU is set, but recommended, the first few sentences are a bit confusing. The rest of the paragraph is clear in terms of MTI and recommendations when TLD/DTLS is used as well as alternates options supporting the listed desired security properties. Security Considerations BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality. From nobody Thu Mar 5 08:14:23 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1AF6F1A0430; Thu, 5 Mar 2015 07:24:26 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC861A0381; Thu, 5 Mar 2015 07:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTUIt-Z-Dogc; Thu, 5 Mar 2015 07:24:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 971111A1A8D; Thu, 5 Mar 2015 07:22:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305152202.28872.54032.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 07:22:02 -0800 Archived-At: X-Mailman-Approved-At: Thu, 05 Mar 2015 08:14:17 -0800 Cc: mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, bfcpbis-chairs@ietf.org Subject: [bfcpbis] Kathleen Moriarty's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 15:24:26 -0000 Kathleen Moriarty 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: ---------------------------------------------------------------------- Thanks for your work on this draft, it was very well written which is much appreciated. I just have one item I'd like to discuss that should be very easy to resolve. This should be considered with Spencer's question on what happens when the fragments are larger or smaller than the path MTU. It's important to state this to prevent fragmentation overlap attacks (unless you can explain why we don't need to worry about that). In the second sentence on page 42, adding the ending clause may be helpful: The size of each of these N messages MUST be smaller than the path MTU to help prevent fragmentation overlap attacks. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Spencer asked what happens when TLS/DTLS is not used, so perhaps rewording of the intro to the security considerations section would help to clear up his point. TLS/DTLS is the MTI with flexibility left in to support some other undefined mechanism to secure the channel. Since no MTU is set, but recommended, the first few sentences are a bit confusing. The rest of the paragraph is clear in terms of MTI and recommendations when TLD/DTLS is used as well as alternates options supporting the listed desired security properties. Security Considerations BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality. From nobody Thu Mar 5 08:24:17 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2193A1A1BF6; Thu, 5 Mar 2015 08:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4jlJRoUL4bs; Thu, 5 Mar 2015 08:24:10 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B4C1A1A7B; Thu, 5 Mar 2015 08:14:14 -0800 (PST) Received: by lbvp9 with SMTP id p9so29415099lbv.8; Thu, 05 Mar 2015 08:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SNEcgs1mjOUA+cHaSHoaOBxaaMBxjyuGAdBRwjPBSos=; b=i/P1VTMUBj4XoOnkOZBvB8+NPUfzEuN2/aPEnfvWJen5gx6Mm3ZFD4UU46g6Yf8va2 2C3RpHwxA8dKT/U/5QmK8lMbUZ0ufYROMiI0RMD3cdPV/wHWH0TWi5ldcmEGfIbm1dTt yvremkLDhEitURcCLP3n2u64ChrdonIE9KqImLce+4bIOyoiXKgSmo2DZQiB6webGKPU 4Rfmc9UcJlhfvmdbt2ZYv5RTAIUYRUJ7Eh4SjRXTr3+3Qjo9zNyaiGAkCdw0g/5KNSt5 Kiy8qe3pn7UCMA5TlNTxtCOGzpRu1LFquLzjDf8ikOA8wKfu1d3u8Otebj0+xBj/DvHa XktQ== MIME-Version: 1.0 X-Received: by 10.152.45.1 with SMTP id i1mr8625097lam.61.1425572052639; Thu, 05 Mar 2015 08:14:12 -0800 (PST) Received: by 10.152.22.100 with HTTP; Thu, 5 Mar 2015 08:14:12 -0800 (PST) In-Reply-To: <20150305152202.28872.54032.idtracker@ietfa.amsl.com> References: <20150305152202.28872.54032.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 10:14:12 -0600 Message-ID: From: Spencer Dawkins at IETF To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a11c27c84cca35f05108cdb53 Archived-At: Cc: bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, Mary Barnes , The IESG , bfcpbis-chairs@ietf.org Subject: Re: [bfcpbis] Kathleen Moriarty's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:24:13 -0000 --001a11c27c84cca35f05108cdb53 Content-Type: text/plain; charset=UTF-8 Just continuing the trend of ADs talking to each other in ballot threads :-) On Thu, Mar 5, 2015 at 9:22 AM, Kathleen Moriarty < Kathleen.Moriarty.ietf@gmail.com> wrote: > Kathleen Moriarty 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: > ---------------------------------------------------------------------- > > Thanks for your work on this draft, it was very well written which is > much appreciated. > > I just have one item I'd like to discuss that should be very easy to > resolve. > This should be considered with Spencer's question on what happens when > the fragments are larger or smaller than the path MTU. It's important to > state this to prevent fragmentation overlap attacks (unless you can > explain why we don't need to worry about that). > > In the second sentence on page 42, adding the ending clause may be > helpful: > The size of each of these N messages MUST be > smaller than the path MTU to help prevent fragmentation overlap > attacks. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Spencer asked what happens when TLS/DTLS is not used, so perhaps > rewording of the intro to the security considerations section would help > to clear up his point. TLS/DTLS is the MTI with flexibility left in to > support some other undefined mechanism to secure the channel. Since no > MTU is set, but recommended, the first few sentences are a bit confusing. > The rest of the paragraph is clear in terms of MTI and recommendations > when TLD/DTLS is used as well as alternates options supporting the listed > desired security properties. I think what I was wondering, was whether it's obvious that it's easier to off-path attack UDP protocols than TCP protocols in general, since an attacker has to splice attack packets into the TCP sequence numbering, while UDP doesn't have the same ... I don't want to say "protection", but maybe "obstacle". So, DTLS is in some sense more helpful than TLS, in resisting off-path attacks. Kathleen being the security type that I'll never be, please pay more attention to her thoughts about this than mine! Spencer > Security Considerations > > BFCP uses TLS/DTLS to provide mutual authentication between clients > and servers. TLS/DTLS also provides replay and integrity protection > and confidentiality. > > > --001a11c27c84cca35f05108cdb53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just continuing the trend of ADs talking to each other in = ballot threads :-)

On Thu, Mar 5, 2015 at 9:22 AM, Kathleen Moriarty &l= t;Kat= hleen.Moriarty.ietf@gmail.com> wrote:
Kathleen Moriarty has entered the following ballot position for<= br> 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-crit= eria.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-rfc458= 2bis/



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

Thanks for your work on this draft, it was very well written which is
much appreciated.

I just have one item I'd like to discuss that should be very easy to resolve.
This should be considered with Spencer's question on what happens when<= br> the fragments are larger or smaller than the path MTU.=C2=A0 It's impor= tant to
state this to prevent fragmentation overlap attacks (unless you can
explain why we don't need to worry about that).

In the second sentence on page 42, adding the ending clause may be
helpful:
=C2=A0 The size of each of these N messages MUST be
=C2=A0 =C2=A0smaller than the path MTU to help prevent fragmentation overla= p
attacks.


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


Spencer asked what happens when TLS/DTLS is not used, so perhaps
rewording of the intro to the security considerations section would help to clear up his point.=C2=A0 TLS/DTLS is the MTI with flexibility left in t= o
support some other undefined mechanism to secure the channel.=C2=A0 Since n= o
MTU is set, but recommended, the first few sentences are a bit confusing. =C2=A0The rest of the paragraph is clear in terms of MTI and recommendation= s
when TLD/DTLS is used as well as alternates options supporting the listed desired security properties.

I think what I= was wondering, was whether it's obvious that it's easier to off-pa= th attack UDP protocols than TCP protocols in general, since an attacker ha= s to splice attack packets into the TCP sequence numbering, while UDP doesn= 't have the same ... I don't want to say "protection", bu= t maybe "obstacle". So, DTLS is in some sense more helpful than T= LS, in resisting off-path attacks.

Kathleen being = the security type that I'll never be, please pay more attention to her = thoughts about this than mine!

Spencer
= =C2=A0
Security Considerations

=C2=A0 =C2=A0BFCP uses TLS/DTLS to provide mutual authentication between cl= ients
=C2=A0 =C2=A0and servers.=C2=A0 TLS/DTLS also provides replay and integrity= protection
=C2=A0 =C2=A0and confidentiality.



--001a11c27c84cca35f05108cdb53-- From nobody Thu Mar 5 08:24:18 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 43A331A1BFA; Thu, 5 Mar 2015 08:24:13 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2193A1A1BF6; Thu, 5 Mar 2015 08:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4jlJRoUL4bs; Thu, 5 Mar 2015 08:24:10 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B4C1A1A7B; Thu, 5 Mar 2015 08:14:14 -0800 (PST) Received: by lbvp9 with SMTP id p9so29415099lbv.8; Thu, 05 Mar 2015 08:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SNEcgs1mjOUA+cHaSHoaOBxaaMBxjyuGAdBRwjPBSos=; b=i/P1VTMUBj4XoOnkOZBvB8+NPUfzEuN2/aPEnfvWJen5gx6Mm3ZFD4UU46g6Yf8va2 2C3RpHwxA8dKT/U/5QmK8lMbUZ0ufYROMiI0RMD3cdPV/wHWH0TWi5ldcmEGfIbm1dTt yvremkLDhEitURcCLP3n2u64ChrdonIE9KqImLce+4bIOyoiXKgSmo2DZQiB6webGKPU 4Rfmc9UcJlhfvmdbt2ZYv5RTAIUYRUJ7Eh4SjRXTr3+3Qjo9zNyaiGAkCdw0g/5KNSt5 Kiy8qe3pn7UCMA5TlNTxtCOGzpRu1LFquLzjDf8ikOA8wKfu1d3u8Otebj0+xBj/DvHa XktQ== MIME-Version: 1.0 X-Received: by 10.152.45.1 with SMTP id i1mr8625097lam.61.1425572052639; Thu, 05 Mar 2015 08:14:12 -0800 (PST) Received: by 10.152.22.100 with HTTP; Thu, 5 Mar 2015 08:14:12 -0800 (PST) In-Reply-To: <20150305152202.28872.54032.idtracker@ietfa.amsl.com> References: <20150305152202.28872.54032.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 10:14:12 -0600 Message-ID: From: Spencer Dawkins at IETF To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a11c27c84cca35f05108cdb53 Archived-At: Cc: bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, Mary Barnes , The IESG , bfcpbis-chairs@ietf.org Subject: Re: [bfcpbis] Kathleen Moriarty's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:24:13 -0000 --001a11c27c84cca35f05108cdb53 Content-Type: text/plain; charset=UTF-8 Just continuing the trend of ADs talking to each other in ballot threads :-) On Thu, Mar 5, 2015 at 9:22 AM, Kathleen Moriarty < Kathleen.Moriarty.ietf@gmail.com> wrote: > Kathleen Moriarty 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: > ---------------------------------------------------------------------- > > Thanks for your work on this draft, it was very well written which is > much appreciated. > > I just have one item I'd like to discuss that should be very easy to > resolve. > This should be considered with Spencer's question on what happens when > the fragments are larger or smaller than the path MTU. It's important to > state this to prevent fragmentation overlap attacks (unless you can > explain why we don't need to worry about that). > > In the second sentence on page 42, adding the ending clause may be > helpful: > The size of each of these N messages MUST be > smaller than the path MTU to help prevent fragmentation overlap > attacks. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Spencer asked what happens when TLS/DTLS is not used, so perhaps > rewording of the intro to the security considerations section would help > to clear up his point. TLS/DTLS is the MTI with flexibility left in to > support some other undefined mechanism to secure the channel. Since no > MTU is set, but recommended, the first few sentences are a bit confusing. > The rest of the paragraph is clear in terms of MTI and recommendations > when TLD/DTLS is used as well as alternates options supporting the listed > desired security properties. I think what I was wondering, was whether it's obvious that it's easier to off-path attack UDP protocols than TCP protocols in general, since an attacker has to splice attack packets into the TCP sequence numbering, while UDP doesn't have the same ... I don't want to say "protection", but maybe "obstacle". So, DTLS is in some sense more helpful than TLS, in resisting off-path attacks. Kathleen being the security type that I'll never be, please pay more attention to her thoughts about this than mine! Spencer > Security Considerations > > BFCP uses TLS/DTLS to provide mutual authentication between clients > and servers. TLS/DTLS also provides replay and integrity protection > and confidentiality. > > > --001a11c27c84cca35f05108cdb53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just continuing the trend of ADs talking to each other in = ballot threads :-)

On Thu, Mar 5, 2015 at 9:22 AM, Kathleen Moriarty &l= t;Kat= hleen.Moriarty.ietf@gmail.com> wrote:
Kathleen Moriarty has entered the following ballot position for<= br> 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-crit= eria.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-rfc458= 2bis/



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

Thanks for your work on this draft, it was very well written which is
much appreciated.

I just have one item I'd like to discuss that should be very easy to resolve.
This should be considered with Spencer's question on what happens when<= br> the fragments are larger or smaller than the path MTU.=C2=A0 It's impor= tant to
state this to prevent fragmentation overlap attacks (unless you can
explain why we don't need to worry about that).

In the second sentence on page 42, adding the ending clause may be
helpful:
=C2=A0 The size of each of these N messages MUST be
=C2=A0 =C2=A0smaller than the path MTU to help prevent fragmentation overla= p
attacks.


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


Spencer asked what happens when TLS/DTLS is not used, so perhaps
rewording of the intro to the security considerations section would help to clear up his point.=C2=A0 TLS/DTLS is the MTI with flexibility left in t= o
support some other undefined mechanism to secure the channel.=C2=A0 Since n= o
MTU is set, but recommended, the first few sentences are a bit confusing. =C2=A0The rest of the paragraph is clear in terms of MTI and recommendation= s
when TLD/DTLS is used as well as alternates options supporting the listed desired security properties.

I think what I= was wondering, was whether it's obvious that it's easier to off-pa= th attack UDP protocols than TCP protocols in general, since an attacker ha= s to splice attack packets into the TCP sequence numbering, while UDP doesn= 't have the same ... I don't want to say "protection", bu= t maybe "obstacle". So, DTLS is in some sense more helpful than T= LS, in resisting off-path attacks.

Kathleen being = the security type that I'll never be, please pay more attention to her = thoughts about this than mine!

Spencer
= =C2=A0
Security Considerations

=C2=A0 =C2=A0BFCP uses TLS/DTLS to provide mutual authentication between cl= ients
=C2=A0 =C2=A0and servers.=C2=A0 TLS/DTLS also provides replay and integrity= protection
=C2=A0 =C2=A0and confidentiality.



--001a11c27c84cca35f05108cdb53-- From nobody Sat Mar 7 06:18:11 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5015D1A9077; Sat, 7 Mar 2015 06:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaQSJfiYsy94; Sat, 7 Mar 2015 06:18:05 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1851A9069; Sat, 7 Mar 2015 06:18:04 -0800 (PST) Received: by qgfh3 with SMTP id h3so19113994qgf.2; Sat, 07 Mar 2015 06:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aU/PKGHEtrqxE7gulWNtnGkO2422+UsrtdldPDDl5dQ=; b=qXBdqYlb6Dw051/pVK8AhQRo8y/SbbZ7v7BMqxhJYwCEQXnVqyLxoKEibMIWhJBvho J0kn1D1O3zPlTQohWhxaCM8BqO0XWeOgZ8hKxXg57IYemSqkgQ/PxyMcYOeNlxfuW8Vk je0Z5BgdYiApTRcO1jp6gRFFflpOsnhomnPMW1MalBGes5QenANlGhev+8kZ4P8PpMVD oc/vvubYZuIb+9Mslr4IPhQRcmG+A8BfJee2burlbBhGHW/l+0S28rB6iSxpJUUWJvu8 tk4PmKyehnkxmgRzl8rcNjvX0g5UpycPk9rowbf8Em4tqpGm6MGsshOLRatmwuGgoZ0a nRxw== X-Received: by 10.229.80.72 with SMTP id s8mr26092180qck.24.1425737884150; Sat, 07 Mar 2015 06:18:04 -0800 (PST) Received: from [10.74.85.4] (mobile-107-107-62-30.mycingular.net. [107.107.62.30]) by mx.google.com with ESMTPSA id o7sm7823890qge.8.2015.03.07.06.17.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Mar 2015 06:18:01 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-4A8BD875-448B-44AE-9B21-D59202B2A280 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sat, 7 Mar 2015 09:17:45 -0500 Content-Transfer-Encoding: 7bit Message-Id: <42DE91B0-AB46-49A0-9513-7420CF3463F4@gmail.com> References: <20150305152202.28872.54032.idtracker@ietfa.amsl.com> To: Spencer Dawkins at IETF Archived-At: Cc: "bfcpbis@ietf.org" , "draft-ietf-bfcpbis-rfc4582bis.all@ietf.org" , Mary Barnes , The IESG , "bfcpbis-chairs@ietf.org" Subject: Re: [bfcpbis] Kathleen Moriarty's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 14:18:07 -0000 --Apple-Mail-4A8BD875-448B-44AE-9B21-D59202B2A280 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Mar 5, 2015, at 11:14 AM, Spencer Dawkins at IETF wrote: >=20 > Just continuing the trend of ADs talking to each other in ballot threads := -) >=20 >> On Thu, Mar 5, 2015 at 9:22 AM, Kathleen Moriarty wrote: >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-bfcpbis-rfc4582bis-13: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> Thanks for your work on this draft, it was very well written which is >> much appreciated. >>=20 >> I just have one item I'd like to discuss that should be very easy to >> resolve. >> This should be considered with Spencer's question on what happens when >> the fragments are larger or smaller than the path MTU. It's important to= >> state this to prevent fragmentation overlap attacks (unless you can >> explain why we don't need to worry about that). >>=20 >> In the second sentence on page 42, adding the ending clause may be >> helpful: >> The size of each of these N messages MUST be >> smaller than the path MTU to help prevent fragmentation overlap >> attacks. >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >>=20 >> Spencer asked what happens when TLS/DTLS is not used, so perhaps >> rewording of the intro to the security considerations section would help >> to clear up his point. TLS/DTLS is the MTI with flexibility left in to >> support some other undefined mechanism to secure the channel. Since no >> MTU is set, but recommended, the first few sentences are a bit confusing.= >> The rest of the paragraph is clear in terms of MTI and recommendations >> when TLD/DTLS is used as well as alternates options supporting the listed= >> desired security properties. >=20 > I think what I was wondering, was whether it's obvious that it's easier to= off-path attack UDP protocols than TCP protocols in general, since an attac= ker has to splice attack packets into the TCP sequence numbering, while UDP d= oesn't have the same ... I don't want to say "protection", but maybe "obstac= le". So, DTLS is in some sense more helpful than TLS, in resisting off-path a= ttacks. >=20 Interesting, it would be good to understand this as well. Thanks for catchi= ng this and raising the question. > Kathleen being the security type that I'll never be, please pay more atten= tion to her thoughts about this than mine! Spencer is humble, please do answer his questions as well! Thanks, Kathleen >=20 > Spencer > =20 >> Security Considerations >>=20 >> BFCP uses TLS/DTLS to provide mutual authentication between clients >> and servers. TLS/DTLS also provides replay and integrity protection >> and confidentiality. >=20 --Apple-Mail-4A8BD875-448B-44AE-9B21-D59202B2A280 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Mar 5, 2015, at 11:14 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrot= e:

Just continu= ing the trend of ADs talking to each other in ballot threads :-)

On Thu, Mar 5, 2015 at 9:2= 2 AM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com= > wrote:
Kathleen Moriarty has ent= ered 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-criter= ia.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-rfc4582b= is/



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

Thanks for your work on this draft, it was very well written which is
much appreciated.

I just have one item I'd like to discuss that should be very easy to
resolve.
This should be considered with Spencer's question on what happens when
the fragments are larger or smaller than the path MTU.  It's important t= o
state this to prevent fragmentation overlap attacks (unless you can
explain why we don't need to worry about that).

In the second sentence on page 42, adding the ending clause may be
helpful:
  The size of each of these N messages MUST be
   smaller than the path MTU to help prevent fragmentation overlap=
attacks.


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


Spencer asked what happens when TLS/DTLS is not used, so perhaps
rewording of the intro to the security considerations section would help
= to clear up his point.  TLS/DTLS is the MTI with flexibility left in to=
support some other undefined mechanism to secure the channel.  Since no=
MTU is set, but recommended, the first few sentences are a bit confusing.  The rest of the paragraph is clear in terms of MTI and recommendations=
when TLD/DTLS is used as well as alternates options supporting the listed desired security properties.

I think what I w= as wondering, was whether it's obvious that it's easier to off-path attack U= DP protocols than TCP protocols in general, since an attacker has to splice a= ttack packets into the TCP sequence numbering, while UDP doesn't have the sa= me ... I don't want to say "protection", but maybe "obstacle". So, DTLS is i= n some sense more helpful than TLS, in resisting off-path attacks.


Interesting, i= t would be good to understand this as well.  Thanks for catching this a= nd raising the question.

Kathleen bei= ng the security type that I'll never be, please pay more attention to her th= oughts about this than mine!
=
Spencer is humble, please do answer his questions as well!

Thanks,
Kathleen

Spencer
 
, "draft-ietf-bfcpbis-rfc4582bis.all@ietf.org" , Mary Barnes , The IESG , "bfcpbis-chairs@ietf.org" Subject: Re: [bfcpbis] Kathleen Moriarty's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 14:18:07 -0000 --Apple-Mail-4A8BD875-448B-44AE-9B21-D59202B2A280 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Mar 5, 2015, at 11:14 AM, Spencer Dawkins at IETF wrote: >=20 > Just continuing the trend of ADs talking to each other in ballot threads := -) >=20 >> On Thu, Mar 5, 2015 at 9:22 AM, Kathleen Moriarty wrote: >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-bfcpbis-rfc4582bis-13: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> Thanks for your work on this draft, it was very well written which is >> much appreciated. >>=20 >> I just have one item I'd like to discuss that should be very easy to >> resolve. >> This should be considered with Spencer's question on what happens when >> the fragments are larger or smaller than the path MTU. It's important to= >> state this to prevent fragmentation overlap attacks (unless you can >> explain why we don't need to worry about that). >>=20 >> In the second sentence on page 42, adding the ending clause may be >> helpful: >> The size of each of these N messages MUST be >> smaller than the path MTU to help prevent fragmentation overlap >> attacks. >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >>=20 >> Spencer asked what happens when TLS/DTLS is not used, so perhaps >> rewording of the intro to the security considerations section would help >> to clear up his point. TLS/DTLS is the MTI with flexibility left in to >> support some other undefined mechanism to secure the channel. Since no >> MTU is set, but recommended, the first few sentences are a bit confusing.= >> The rest of the paragraph is clear in terms of MTI and recommendations >> when TLD/DTLS is used as well as alternates options supporting the listed= >> desired security properties. >=20 > I think what I was wondering, was whether it's obvious that it's easier to= off-path attack UDP protocols than TCP protocols in general, since an attac= ker has to splice attack packets into the TCP sequence numbering, while UDP d= oesn't have the same ... I don't want to say "protection", but maybe "obstac= le". So, DTLS is in some sense more helpful than TLS, in resisting off-path a= ttacks. >=20 Interesting, it would be good to understand this as well. Thanks for catchi= ng this and raising the question. > Kathleen being the security type that I'll never be, please pay more atten= tion to her thoughts about this than mine! Spencer is humble, please do answer his questions as well! Thanks, Kathleen >=20 > Spencer > =20 >> Security Considerations >>=20 >> BFCP uses TLS/DTLS to provide mutual authentication between clients >> and servers. TLS/DTLS also provides replay and integrity protection >> and confidentiality. >=20 --Apple-Mail-4A8BD875-448B-44AE-9B21-D59202B2A280 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Mar 5, 2015, at 11:14 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrot= e:

Just continu= ing the trend of ADs talking to each other in ballot threads :-)

On Thu, Mar 5, 2015 at 9:2= 2 AM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com= > wrote:
Kathleen Moriarty has ent= ered 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-criter= ia.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-rfc4582b= is/



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

Thanks for your work on this draft, it was very well written which is
much appreciated.

I just have one item I'd like to discuss that should be very easy to
resolve.
This should be considered with Spencer's question on what happens when
the fragments are larger or smaller than the path MTU.  It's important t= o
state this to prevent fragmentation overlap attacks (unless you can
explain why we don't need to worry about that).

In the second sentence on page 42, adding the ending clause may be
helpful:
  The size of each of these N messages MUST be
   smaller than the path MTU to help prevent fragmentation overlap=
attacks.


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


Spencer asked what happens when TLS/DTLS is not used, so perhaps
rewording of the intro to the security considerations section would help
= to clear up his point.  TLS/DTLS is the MTI with flexibility left in to=
support some other undefined mechanism to secure the channel.  Since no=
MTU is set, but recommended, the first few sentences are a bit confusing.  The rest of the paragraph is clear in terms of MTI and recommendations=
when TLD/DTLS is used as well as alternates options supporting the listed desired security properties.

I think what I w= as wondering, was whether it's obvious that it's easier to off-path attack U= DP protocols than TCP protocols in general, since an attacker has to splice a= ttack packets into the TCP sequence numbering, while UDP doesn't have the sa= me ... I don't want to say "protection", but maybe "obstacle". So, DTLS is i= n some sense more helpful than TLS, in resisting off-path attacks.


Interesting, i= t would be good to understand this as well.  Thanks for catching this a= nd raising the question.

Kathleen bei= ng the security type that I'll never be, please pay more attention to her th= oughts about this than mine!
=
Spencer is humble, please do answer his questions as well!

Thanks,
Kathleen

Spencer
 
X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309221845.29139.33135.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 15:18:45 -0700 Archived-At: Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-bfcp-websocket-03.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:18:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. Title : The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) Authors : Victor Pascual Anton Roman Stephane Cazeaux Gonzalo Salgueiro Ram Mohan Ravindranath Sergio Garcia Murillo Filename : draft-ietf-bfcpbis-bfcp-websocket-03.txt Pages : 13 Date : 2015-03-09 Abstract: The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) entities to enable usage of BFCP in new scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-bfcp-websocket/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-bfcp-websocket-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-bfcp-websocket-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 15:31:18 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9381A87C0 for ; Mon, 9 Mar 2015 15:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2w9-yeLvGZ1H for ; Mon, 9 Mar 2015 15:31:14 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2D91A8830 for ; Mon, 9 Mar 2015 15:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3787; q=dns/txt; s=iport; t=1425940270; x=1427149870; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/BkVDUV8rbsiVVBKCWQb8XllyMB6u2ndaSJVWGpfklQ=; b=FcDW6tgWWVqgEqpH4aZkkhSRwibKxFeZvQro/DWJ1hwUKx/+I0bAwZbY 8BDm7NhGRWqVDP/f9c/gu0WFpNIefTbWWfVldYAJbLdpmmjb0MBQzujVd B9QnEinP+Aa8qOtHgfatOqXgedNhDg90wA+yoeEc/CYkq4y2rjLhaTeEP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AGDQDQHf5U/4gNJK1cgwZSWgTAOII2hXACgStNAQEBAQEBfIQPAQEBAwE6PwULAgEIGB4QMiUCBA4FiCcIDcEUAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLF4E9AYJ9MweDF4EWBYV5iBSCAoNkhW+BGoMoiFODHYNCI4ICDQ+BUG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,370,1422921600"; d="scan'208";a="130383483" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP; 09 Mar 2015 22:31:10 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t29MV9MC024488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 22:31:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.150]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 17:31:09 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Christer Holmberg Thread-Topic: [bfcpbis] reminder to review draft-ietf-bfcpbis-bfcp-websocket-01 Thread-Index: AQHQWri9LQFkdusQ+UqoonBfPjC2Sw== Date: Mon, 9 Mar 2015 22:31:09 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4C7E90@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C7E90@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.178.224] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" Subject: Re: [bfcpbis] reminder to review draft-ietf-bfcpbis-bfcp-websocket-01 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:31:16 -0000 Hi Christer -=20 We have submitted a new version of the draft (-03) that addresses your rema= ining comments. This includes separating the WS/WSS Connection URI definit= ion and registration to a separate draft (See https://tools.ietf.org/html/d= raft-ram-bfcpbis-sdp-ws-uri-00). At your convenience please have a look and see if your comments are satisfa= ctorily addressed by both drafts. Thanks! Gonzalo > On Oct 25, 2014, at 7:40 AM, Christer Holmberg wrote: >=20 > Hi, >=20 >>> Section 3: >>> ------------ >>>=20 >>> Q3_1: Why is this section needed? The draft is not a teach-yourself-web= socket document, is it? :) >>>=20 >>> In my opinion the draft should reference the WebSocket RFC for= general information about WebSocket, and=20 >>> the draft then describes the BFCP specifics - ie what is describ= ed in section 4. >>>=20 >>> Otherwise, if some details of WebSocket change in the future, = you may have to update this RFC=20 >>> also - even if the change does not affect the BFCP usage of We= bSocket. >>=20 >> A bit of explanatory text was requested in early reviews. I myself find= it useful to provide modest=20 >> baseline information self-contained in the document. This is also commo= n practice in all the foo=20 >> over WebSockets documents, including RFC 7118. That said, if you feel s= trongly it should be removed, we can do so.=20 >=20 > If you want to keep it, I will withdraw my comment. It's just an editoria= l thing :) >=20 > ... >=20 >>> Q6_2: Is the new SDP ws-uri attribute BFCP specific? If not, should it = be in a separate draft? >>=20 >> No, it isn't BFCP-specific and your point makes sense. Having a general= SDP attribute for SDP negotiated=20 >> protocols over Websocket is meaningful and would facilitate future proto= cols over Websocket. Once I create=20 >> a new draft I'll remove this bit of text and replace it with a reference= to the new document. Expect this for the -03 version. >=20 >>> Q6_3: I think it would be good to have a reference to a document which = talks more about the URI matching requirement. >>>=20 >>> Something like: "As defined in section YYYY of RFC XXXX, when = using Secure Websockets the CNAME=20 >>> of the SSL certificate must match the WebSocket connection URI= host..." >>=20 >> I agree with the comment, but not sure what the reference should be. Not= sure what will be the correct reference.=20 >> Do you think something like RFC 2818 Section 3 would work? >=20 > I don't know where the requirement comes from, but I assume it must be de= fined somewhere :) >=20 > Anyway, if you move the SDP ws-uri attribute definition into a separate d= raft I assume this text would also be in that draft. >=20 >>> Q6_4: As you define a new SDP attribute, you should have a "SDP Offer/A= nswer Proceudures" section. >>=20 >> Do you mean an Offer/Answer sections in line with RFC 3264 that has the = following sub-sections with relevant procedures called out? >>=20 >> 1) Generating the Initial Offer >> 2) Generating the Answer >> 3) Offerer Processing of the Answer >> 4) Modify the Session >>=20 >> Something like what we did in Section 4 of RFC 7345? >=20 > Correct. >=20 > Again, if you move the attribute definition to a separate draft, you only= need to define the O/A procedures for the new m- line transport field valu= es in this draft. >=20 >> If so, that will take me a bit of time and will need to wait until -03 a= s I have much to do before the submission deadline. >=20 > That is ok. I guess you could put the section names into -02, and add the= content later. >=20 > Regards, >=20 > Christer From nobody Tue Mar 10 01:52:48 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9A51A701C for ; Tue, 10 Mar 2015 01:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFAvmW16DRF8 for ; Tue, 10 Mar 2015 01:52:41 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94E61A700A for ; Tue, 10 Mar 2015 01:52:40 -0700 (PDT) X-AuditID: c1b4fb30-f79c86d000000fc0-63-54feb0d648d9 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 26.9E.04032.6D0BEF45; Tue, 10 Mar 2015 09:52:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0210.002; Tue, 10 Mar 2015 09:52:38 +0100 From: Christer Holmberg To: "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [bfcpbis] reminder to review draft-ietf-bfcpbis-bfcp-websocket-01 Thread-Index: AQHQWri9LQFkdusQ+UqoonBfPjC2S50VabEQ Date: Tue, 10 Mar 2015 08:52:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D733A1E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C7E90@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvje71Df9CDA4381n8W3eUyWLTrC9s FnOn+Dkwe0z5vZHVY8mSn0wBTFFcNimpOZllqUX6dglcGZ3/21gKZihUPP55lLWBcZ1kFyMn h4SAicTjI/uYIWwxiQv31rN1MXJxCAkcYZT4t+EzK0hCSGAJo8TOP7ZdjBwcbAIWEt3/tEHC IgLmEnt+t7CBhJkFoiQ+7GAEMYUFAiSevayEqAiUuNM9nwXCNpK4ueoE2CYWAVWJ0w+3MYOU 8wr4Ssw4wAKxtIFR4tOZ2YwgNZwCthITX31jArEZgS77fmoNmM0sIC5x68l8JoiLBSSW7DkP db2oxMvH/1ghbCWJRbc/Q9XrSCzY/YkNwtaWWLbwNVg9r4CgxMmZT1gmMIrNQjJ2FpKWWUha ZiFpWcDIsopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMIIObvltsIPx5XPHQ4wCHIxKPLwG cf9ChFgTy4orcw8xSnOwKInz2hkfChESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAmLznaf2H 9ddZDNf9a/bL/HTpjEJwS8Y9jbmnKjo7eL4EMpsnne2t3/idQ9RRKHdV/q5/ixu5N0q7prGd frOg5zrv2jVT9l/rLT5+6E6qLM+euULl3i2K2rt5sl+p3GG4MaFEvUur9rpyUmNNZ5SQLZfK Nz2mFZ8lviwMdvwmcyvaeN7sFuUyJZbijERDLeai4kQA/H1h+4ECAAA= Archived-At: Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" Subject: Re: [bfcpbis] reminder to review draft-ietf-bfcpbis-bfcp-websocket-01 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 08:52:46 -0000 Hi, I'll take a look. Regards, Christer -----Original Message----- From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com]=20 Sent: 10 March 2015 00:31 To: Christer Holmberg Cc: Charles Eckel (eckelcu); bfcpbis@ietf.org Subject: Re: [bfcpbis] reminder to review draft-ietf-bfcpbis-bfcp-websocket= -01 Hi Christer -=20 We have submitted a new version of the draft (-03) that addresses your rema= ining comments. This includes separating the WS/WSS Connection URI definit= ion and registration to a separate draft (See https://tools.ietf.org/html/d= raft-ram-bfcpbis-sdp-ws-uri-00). At your convenience please have a look and see if your comments are satisfa= ctorily addressed by both drafts. Thanks! Gonzalo > On Oct 25, 2014, at 7:40 AM, Christer Holmberg wrote: >=20 > Hi, >=20 >>> Section 3: >>> ------------ >>>=20 >>> Q3_1: Why is this section needed? The draft is not a=20 >>> teach-yourself-websocket document, is it? :) >>>=20 >>> In my opinion the draft should reference the WebSocket RFC for= general information about WebSocket, and=20 >>> the draft then describes the BFCP specifics - ie what is describ= ed in section 4. >>>=20 >>> Otherwise, if some details of WebSocket change in the future, = you may have to update this RFC=20 >>> also - even if the change does not affect the BFCP usage of We= bSocket. >>=20 >> A bit of explanatory text was requested in early reviews. I myself=20 >> find it useful to provide modest baseline information self-contained=20 >> in the document. This is also common practice in all the foo over WebSo= ckets documents, including RFC 7118. That said, if you feel strongly it sh= ould be removed, we can do so. >=20 > If you want to keep it, I will withdraw my comment. It's just an=20 > editorial thing :) >=20 > ... >=20 >>> Q6_2: Is the new SDP ws-uri attribute BFCP specific? If not, should it = be in a separate draft? >>=20 >> No, it isn't BFCP-specific and your point makes sense. Having a=20 >> general SDP attribute for SDP negotiated protocols over Websocket is=20 >> meaningful and would facilitate future protocols over Websocket. Once I = create a new draft I'll remove this bit of text and replace it with a refer= ence to the new document. Expect this for the -03 version. >=20 >>> Q6_3: I think it would be good to have a reference to a document which = talks more about the URI matching requirement. >>>=20 >>> Something like: "As defined in section YYYY of RFC XXXX, when = using Secure Websockets the CNAME=20 >>> of the SSL certificate must match the WebSocket connection URI= host..." >>=20 >> I agree with the comment, but not sure what the reference should be. Not= sure what will be the correct reference.=20 >> Do you think something like RFC 2818 Section 3 would work? >=20 > I don't know where the requirement comes from, but I assume it must be=20 > defined somewhere :) >=20 > Anyway, if you move the SDP ws-uri attribute definition into a separate d= raft I assume this text would also be in that draft. >=20 >>> Q6_4: As you define a new SDP attribute, you should have a "SDP Offer/A= nswer Proceudures" section. >>=20 >> Do you mean an Offer/Answer sections in line with RFC 3264 that has the = following sub-sections with relevant procedures called out? >>=20 >> 1) Generating the Initial Offer >> 2) Generating the Answer >> 3) Offerer Processing of the Answer >> 4) Modify the Session >>=20 >> Something like what we did in Section 4 of RFC 7345? >=20 > Correct. >=20 > Again, if you move the attribute definition to a separate draft, you only= need to define the O/A procedures for the new m- line transport field valu= es in this draft. >=20 >> If so, that will take me a bit of time and will need to wait until -03 a= s I have much to do before the submission deadline. >=20 > That is ok. I guess you could put the section names into -02, and add the= content later. >=20 > Regards, >=20 > Christer From nobody Mon Mar 23 22:37:38 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856E91A037C; Mon, 23 Mar 2015 22:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWRqgdSMGBqn; Mon, 23 Mar 2015 22:37:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86ACC1B2C96; Mon, 23 Mar 2015 22:37:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324053731.19935.67456.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 22:37:31 -0700 Archived-At: Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-bfcp-websocket-04.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 05:37:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. Title : The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) Authors : Victor Pascual Anton Roman Stephane Cazeaux Gonzalo Salgueiro Ram Mohan Ravindranath Sergio Garcia Murillo Filename : draft-ietf-bfcpbis-bfcp-websocket-04.txt Pages : 13 Date : 2015-03-23 Abstract: The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) entities to enable usage of BFCP in new scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-bfcp-websocket/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-bfcp-websocket-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-bfcp-websocket-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/