Re: [Gen-art] Review of draft-ietf-bfcpbis-bfcp-websocket-13

[Ram Mohan R (rmohanr)]

Just to close this thread. We had an offline discussion with Robert and posted 
a new revision with his comments incorporated. Below are the changes

In security consideration section we added:
When using BFCP over websockets, the security mechanisms defined in
   [I-D.ietf-bfcpbis-rfc4582bis] are not used.  Instead, the application
   is required to build and rely on the security mechanisms in
   [RFC6455].

On the point about websocket libraries giving the application the control to 
select the algorithm to use for TLS setup, there is no such control provided by 
the current WS API 
at https://www.w3.org/TR/2012/CR-websockets-20120920/ WebSocket W3C API spec 

New revision published with Roberts comments: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-bfcp-websocket-14

Regards,
Ram

-Original Message-
From: Robert Sparks <rjspa...@nostrum.com>
Date: Tuesday, 17 January 2017 at 8:51 PM
To: "Ram Mohan R (rmohanr)" <rmoh...@cisco.com>, "gen-art@ietf.org" 
<gen-art@ietf.org>
Cc: "draft-ietf-bfcpbis-bfcp-websocket@ietf.org" 
<draft-ietf-bfcpbis-bfcp-websocket@ietf.org>, "bfcp...@ietf.org" 
<bfcp...@ietf.org>, "i...@ietf.org" <i...@ietf.org>
Subject: Re: Review of draft-ietf-bfcpbis-bfcp-websocket-13



On 1/15/17 11:36 PM, Ram Mohan R (rmohanr) wrote:
> Hi Robert,
>
> Thanks for your review. Please see inline 
>
>> -Original Message-
>> From: Robert Sparks <rjspa...@nostrum.com>
>> Date: Thursday, 5 January 2017 at 4:05 AM
>> To: "gen-art@ietf.org" <gen-art@ietf.org>
>> Cc: "draft-ietf-bfcpbis-bfcp-websocket@ietf.org" 
<draft-ietf-bfcpbis-bfcp-websocket@ietf.org>, "bfcp...@ietf.org" 
<bfcp...@ietf.org>, "i...@ietf.org" ><i...@ietf.org>
>> Subject: Review of draft-ietf-bfcpbis-bfcp-websocket-13
>> Resent-From: <alias-boun...@ietf.org>
>> Resent-To: <anton.ro...@quobis.com>, <stephane.caze...@orange.com>, 
<gsalg...@cisco.com>, <sergio.garcia.muri...@gmail.com>, <rmoh...@cisco.com>, 
><victor.pascual.av...@oracle.com>, <keith.dr...@alcatel-lucent.com>, 
<ecke...@cisco.com>, <b...@nostrum.com>, <ali...@cooperw.in>, 
><aamelni...@fastmail.fm>, Charles Eckel <ecke...@cisco.com>
>> Resent-Date: Thursday, 5 January 2017 at 4:05 AM
>>  Reviewer: Robert Sparks
> > Review result: Ready with Issues
>  
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed
> > by the IESG for the IETF Chair.  Please treat these comments just
>  > like any other last call comments.
>  
>  > For more information, please see the FAQ at
>  > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>  >
>  > Document: draft-ietf-bfcpbis-bfcp-websocket13-
>  > Reviewer: Robert Sparks
>  > Review Date: 2017-01-04
>  > IETF LC End Date: 2017-01-11
>  > IESG Telechat date: 2017-01-19
>  >
>  > Summary: Basically ready but with issues that need to be addressed
>  > before publication as a Proposed Standard
>  >
>  > Issues:
>  >
>  > The BFCP spec (at draft-ietf-bfcpbis-rfc4582bis) relies heavily on
>  > recommendations it makes about the use of TLS or DTLS, and even 
goes
>  > to
>  > the point of specifyig a particular set of cipher suites to use wih
>  > those protocols when using them with BFCP. The security
>  > considerations
>  > section of that document details some specific attacks and how the
>  > use
>  > of TLS/DTLS mitigates them (providing some justification for the
>  > cipher
>  > suites that the document specifies).
>  >
>  > This document provides a _COMPLETELY DIFFERENT_ security mechanism
>  > (essentially punting entirely to whatever a websocket library
>  > provides
> > with the expectation that that will also be rooted in TLS) when it
> > substitutes websockets as the layer under BFCP. The security
> > considerations section needs to make this much more obvious -
> > implementers and deployers need to be see this as a strong-primary
> > point to avoid anyone thinking all the thinking that went into
>  > securing
>   >   B

Re: [Gen-art] Review of draft-ietf-bfcpbis-bfcp-websocket-13

[Ram Mohan R (rmohanr)]

Hi Robert,

Thanks for your review. Please see inline 

>-Original Message-
>From: Robert Sparks 
>Date: Thursday, 5 January 2017 at 4:05 AM
>To: "gen-art@ietf.org" 
>Cc: "draft-ietf-bfcpbis-bfcp-websocket@ietf.org" 
>, "bfcp...@ietf.org" 
>, "i...@ietf.org" >
>Subject: Review of draft-ietf-bfcpbis-bfcp-websocket-13
>Resent-From: 
>Resent-To: , , 
>, , , 
>>, , 
>, , , 
>>, Charles Eckel 
>Resent-Date: Thursday, 5 January 2017 at 4:05 AM

  >  Reviewer: Robert Sparks
   > Review result: Ready with Issues

   > I am the assigned Gen-ART reviewer for this draft. The General Area
   > Review Team (Gen-ART) reviews all IETF documents being processed
   > by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.

> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-bfcpbis-bfcp-websocket13-
> Reviewer: Robert Sparks
> Review Date: 2017-01-04
> IETF LC End Date: 2017-01-11
> IESG Telechat date: 2017-01-19
>
> Summary: Basically ready but with issues that need to be addressed
> before publication as a Proposed Standard
>
> Issues: 
>
> The BFCP spec (at draft-ietf-bfcpbis-rfc4582bis) relies heavily on
> recommendations it makes about the use of TLS or DTLS, and even goes
> to
> the point of specifyig a particular set of cipher suites to use wih
> those protocols when using them with BFCP. The security
> considerations
> section of that document details some specific attacks and how the
> use
> of TLS/DTLS mitigates them (providing some justification for the
> cipher
> suites that the document specifies).
>
> This document provides a _COMPLETELY DIFFERENT_ security mechanism
> (essentially punting entirely to whatever a websocket library
> provides
   > with the expectation that that will also be rooted in TLS) when it
   > substitutes websockets as the layer under BFCP. The security
   > considerations section needs to make this much more obvious -
   > implementers and deployers need to be see this as a strong-primary
   > point to avoid anyone thinking all the thinking that went into
> securing
 >   BFCP as captured in draft-ietf-bfcpbis-rfc4582bis still applies.

 I will add the below line in security consideration section. Is this 
sufficient?

NEW:
“The security considerations described in draft-ietf-bfcpbis-rfc4582bis are 
applicable here as well.”

  >  There should be more discussion about what a BFCP implementation that
   > cares about the attacks discussed in section 14 of
   > draft-ietf-bfcpbis-rfc4582bis requires of its library. The current
   > document gets most of the way there, but there are things missing.
>Shouldn't there be some discussion of ensuring the websocket library
   > used supports and will use the cipher suites called out in the core
   > BFCP document? If not, this document needs to be very explicit that
> you
> are only going to get the confidentiality protection the library
> provides.

 Good point. I would prefer to add a text something to the effect of:

“The security considerations mentioned in section 14 of 
[draft-ietf-bfcpbis-rfc4582bis] are applicable here. In order to mitigate
the attacks mentioned in section 14 of [draft-ietf-bfcpbis-rfc4582bis], it is 
RECOMMENDED that the clients and server use secure WebSocket 
with an encryption algorithm according to Section 7 of 
[draft-ietf-bfcpbis-rfc4582bis]”

> The current consideration section calls out relying on "a
 >   typical webserver-client model" and talks about server
  >   authentication,
   > but not client authentication. Section 8 shows most of what you're
   > expecting the server to do to authenticate the client, but you need
   > more text about what you expect the client libraries to be doing to
   > let
   > the server do its job (and you should point back to that from the
   > security considerations section).

 section 8 second para has text on what client should do. Also 4th para 
has some text.  Is there anything else you would like to see in that?
 I will add a line in security considerations

EXISTING:
The security model here is a typical webserver-
   client model where the client validates the server certificate and
   then connects to the server

NEW:
The security model here is a typical webserver-
   client model where the client validates the server certificate and
   then connects to the server. 

Re: [Gen-art] Review of draft-ietf-bfcpbis-sdp-ws-uri-07

[Ram Mohan R (rmohanr)]

Hi Joel,

Thanks for your response. Please see inline

-Original Message-
From: Joel Halpern 
Date: Saturday, 24 December 2016 at 4:45 AM
To: "gen-art@ietf.org" 
Cc: "bfcp...@ietf.org" , "i...@ietf.org" , 
"draft-ietf-bfcpbis-sdp-ws-uri@ietf.org" 

Subject: Review of draft-ietf-bfcpbis-sdp-ws-uri-07
Resent-From: 
Resent-To: , , 
, , , 
, , Charles Eckel 
Resent-Date: Saturday, 24 December 2016 at 4:45 AM

Reviewer: Joel Halpern
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-bfcpbis-sdp-ws-uri-??
Reviewer: Joel Halpern
Review Date: 2016-12-23
IETF LC End Date: 2017-01-12
IESG Telechat date: 2017-01-19

Summary: This document is ready for publication as a Proposed Standard
RFC.  I have a few minor comments that should be considered s they may
improve future understanding of the document.

Major issues: None

Minor issues:
In reading section 4.2 and 4.3, I believe I can guess at certain
intended behaviors, but it is not as clearly stated as I think is
desirable.  There is also one odd statement in section 4.3

Taking the odd statement first, the text in section 4.3 refers the
active answerer "towards
   the IP address and port of the offerer".  But when WebSockets is
used, one does not connect to the IP address and port, but to the URI
specified.

 I will replace the text as below:

EXISTING:
Towards the IP address and port of the offerer using the procedures described
   in [RFC6455]

NEW:
Towards the URI specified in a=ws-uri or a=wss-uri attribute using procedures 
described 
   in [RFC6455]

I believe that the intent in 4.2 and 4.3 is that whichever side
will be "passive" is required to provide an a=ws-uri or a=wss-uri so
that the other side can establish the connection to the URI.  But
section 4.2 does not say that. 


EXISTING:
   The offerer SHOULD assign the SDP "setup" attribute with a value of
   "active" (the offerer will be the initiator of the outgoing TCP
   connection), unless the offerer insists on being a receiver of an
   incoming connection, in which case the offerer SHOULD use a value of
   "passive".  The offerer MUST NOT assign an SDP "setup" attribute with
   a "holdconn" value.

NEW:
   The offerer SHOULD assign the SDP "setup" attribute with a value of
   "active" (the offerer will be the initiator of the outgoing TCP
   connection), unless the offerer insists on being a receiver of an
   incoming connection, in which case the offerer SHOULD use a value of
   "passive".  The offerer MUST NOT assign an SDP "setup" attribute with
   a "holdconn" value. If the “setup” attribute has a value “passive” it MUST 
also
have URI in the a=ws-uri or a=wss-uri attribute.

 And the text in section4.3 that talks
about providing the URI in the a= does not qualify whether it is
required with active, passive, or both.  


NEW:
If the answers assigns SDP “setup” attribute with “passive”, then it MUST have 
URI in either 
a=ws-uri or a=wss-uri attribute.

Does this look good and makes it more clear ?

Regards,
Ram

Nits/editorial comments:  N/A




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-siprec-callflows-07

[Ram Mohan R (rmohanr)]

Hi Jari,

Yes. I just replied to Dan’s comment. Will take care of all of them. Thanks for 
your review.

Regards,
Ram

-Original Message-
From: Jari Arkko 
Date: Thursday, 1 December 2016 at 7:08 PM
To: Dan Romascanu 
Cc: , 
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-siprec-callflows-07
Resent-From: , 
Resent-To: , , 
, , , 
, , , Andrew 
Hutton , 
Resent-Date: Thu, 1 Dec 2016 05:38:11 -0800

Thank you very much for your review, Dan. Authors, have you taken a look at 
Dan’s comments?

Jari

On 25 Nov 2016, at 14:16, Dan Romascanu  wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document:
> 
> draft-ietf-siprec-callflows-07
> 
> Reviewer: Dan Romascanu
> Review Date: 11/25/16
> IETF LC End Date: 11/27/16
> IESG Telechat date: (if known) 12/2/16
> 
> Summary: Ready.
> 
> This is a very useful supporting document in the SIPREC cluster.
> 
> Major issues:
> 
> None
> 
> Minor issues:
> 
> None
> 
> 
> Nits/editorial comments:
> 
> 1. The title is slightly misleading, as the document does not have as 
goal to document all or the most important call flows, but rather to provide a 
grouping of significant examples. 'Examples of SUP Recording Call Flows' may 
have been a better title.
> 
> 2. As the document uses terminology defined in [RFC7865] and [RFC6341], 
listing these two RFCs as Normative References seems necessary (can't 
understand the terms without reading the two RFCs)
> 
> 3. typo in the Securoty Considerations section: '
> 
> Security considerations mentioned in [RFC7865] and [RFC7866] has to be 
followed ...
> 
> s/has to/have to/
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-siprec-callflows-07

[Ram Mohan R (rmohanr)]

Hi Dan,

Thanks for your review. Please see inline

From: Dan Romascanu 
Date: Friday, 25 November 2016 at 5:46 PM
To: "gen-art@ietf.org" , 
"draft-ietf-siprec-callflows@tools.ietf.org" 

Subject: Gen-ART review of draft-ietf-siprec-callflows-07
Resent-From: , 
Resent-To: , , 
, , , 
, , , Andrew 
Hutton , 
Resent-Date: Friday, 25 November 2016 at 5:46 PM

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document:

draft-ietf-siprec-callflows-07

Reviewer: Dan Romascanu
Review Date: 11/25/16
IETF LC End Date: 11/27/16
IESG Telechat date: (if known) 12/2/16

Summary: Ready.

This is a very useful supporting document in the SIPREC cluster.

Major issues:

None

Minor issues:

None


Nits/editorial comments:

1. The title is slightly misleading, as the document does not have as goal to 
document all or the most important call flows, but rather to provide a grouping 
of significant examples. 'Examples of SUP Recording Call Flows' may have been a 
better title.

 I agree. The document contains only most important call flows. So I will 
rename to “Examples of SIP Recording Call Flows”

2. As the document uses terminology defined in [RFC7865] and [RFC6341], listing 
these two RFCs as Normative References seems necessary (can't understand the 
terms without reading the two RFCs)

 agree. Will do that.

3. typo in the Securoty Considerations section: '

Security considerations mentioned in [RFC7865] and [RFC7866] has to be followed 
...

s/has to/have to/

 Thanks will fix it.

Regards
Ram



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-ietf-straw-b2bua-dtls-srtp-08.txt

[Ram Mohan R (rmohanr)]

Hi Francis,

Thanks for your feedback. I will address all your nits.

Regards,
Ram

-Original Message-
From: Francis Dupont 
Date: Wednesday, 18 November 2015 at 1:37 PM
To: "gen-art@ietf.org" 
Cc: "draft-ietf-straw-b2bua-dtls-srtp@ietf.org"

Subject: review of draft-ietf-straw-b2bua-dtls-srtp-08.txt

>I am the assigned Gen-ART reviewer for this draft. The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed
>by the IESG for the IETF Chair.  Please treat these comments just
>like any other last call comments.
>
>For more information, please see the FAQ at
>
>.
>
>Document: draft-ietf-straw-b2bua-dtls-srtp-08.txt
>Reviewer: Francis Dupont
>Review Date: 20151112
>IETF LC End Date: 20151117
>IESG Telechat date: 20151203
>
>Summary: Ready
>
>Major issues: None
>
>Minor issues: None
>
>Nits/editorial comments:
>  (very minor)
>  - 3.1.1 figure 1 page 5: a= fingerprint1 -> a=fingerprint1
>
>  - 7 page 9: comments,suggestions, -> comments, suggestions,
>
>  - Authors' Addresses page 11: as the first two authors work at
>   the same place one can expect exactly the same address (:-)
>
>Regards
>
>francis.dup...@fdupont.fr

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-rtcweb-stun-consent-freshness-13

[Ram Mohan R (rmohanr)]

Hi Meral,

we will be addressing these comments as per the reply I had sent to your email 
. I am currently holding off the edits as we had couple of comments from the WG 
 which Martin is addressing. Once that is taken care, I will address your 
comments.
My responses to your comments are here - 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg14627.html

Regards,
Ram
From: Meral Shirazipour 
meral.shirazip...@ericsson.commailto:meral.shirazip...@ericsson.com
Date: Tuesday, 26 May 2015 10:42 am
To: 
draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.orgmailto:draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org
 
draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.orgmailto:draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org,
 gen-art@ietf.orgmailto:gen-art@ietf.org 
gen-art@ietf.orgmailto:gen-art@ietf.org
Subject: Gen-ART Telechat Call review of 
draft-ietf-rtcweb-stun-consent-freshness-13
Resent-From: 
meral.shirazip...@ericsson.commailto:meral.shirazip...@ericsson.com
Resent-To: 
draft-ietf-rtcweb-stun-consent-freshness@ietf.orgmailto:draft-ietf-rtcweb-stun-consent-freshness@ietf.org
Resent-Date: Tuesday, 26 May 2015 10:43 am

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at  
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please wait for direction from your document shepherd or AD before posting a 
new version of the draft.

Document: draft-ietf-rtcweb-stun-consent-freshness-13
Reviewer: Meral Shirazipour
Review Date: 2015-05-25
IETF LC End Date: 2015-05-15
IESG Telechat date: 2015-05-28



Summary: This draft is ready to be published as Standards Track RFC but I had 
some comments .


Nits/editorial comments:
Please see LC review threads:
http://www.ietf.org/mail-archive/web/gen-art/current/msg11686.html


Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-ietf-straw-b2bua-stun-06.txt

[Ram Mohan R (rmohanr)]

Thanks Francis. I will address the below nits in the next revision.

Ram

-Original Message-
From: Francis Dupont francis.dup...@fdupont.fr
Date: Sunday, 17 May 2015 6:35 pm
To: gen-art@ietf.org gen-art@ietf.org
Cc: draft-ietf-straw-b2bua-stun@tools.ietf.org
draft-ietf-straw-b2bua-stun@tools.ietf.org
Subject: review of draft-ietf-straw-b2bua-stun-06.txt
Resent-From: francis.dup...@fdupont.fr
Resent-To: draft-ietf-straw-b2bua-stun@ietf.org
Resent-Date: Sunday, 17 May 2015 6:40 pm

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

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

Document: draft-ietf-straw-b2bua-stun-06.txt
Reviewer: Francis Dupont
Review Date: 20150515
IETF LC End Date: 20150513
IESG Telechat date: 20150514??

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 I reviewed the 06 version.

 - 1 page 3: signalling - signaling

 - 4.1 page 5: after the terminology section it is recommended to avoid
  lower case keywords (e.g., the may in A B2BUA may be in).

 - 4.4 page 11: a may and a should...

 - authors' addresses pages 13 and 14: India is the full country name,
  US the ISO IS 3166 code (the full name is USA). The current rule
  is to use 3166 two letter codes, I raised a concern as the UPU
  has the opposite rule (full names). Let the RFC Editor to handle this?

Regards

francis.dup...@fdupont.fr

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art