Hello Vijay, thank you for your answer. Your proposed changes resolve my comments. Please note that with the revised text for #4 you have introduced a new spelling error: s/mechanisms that protects confidentiality/mechanisms that protect confidentiality Best regards, Tobias > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@xxxxxxxxxxxxxxxxxx] > Sent: Monday, July 16, 2007 6:15 PM > To: Tobias Gondrom > Cc: secdir@xxxxxxx; iesg@xxxxxxxx; ietf@xxxxxxxx; fluffy@xxxxxxxxx; > karim@xxxxxxxxxxx; oscar.novo@xxxxxxxxxxxx; mary.barnes@xxxxxxxxxx; > jon.peterson@xxxxxxxxxxx; gonzalo.camarillo@xxxxxxxxxxxx; vkg@alcatel- > lucent.com > Subject: Re: [secdir] SecDir review of draft-ietf-sipping-v6-transition-05 > > Tobias Gondrom wrote: > > Hello, > > > > Sam Weiler informed me that this draft will be on telechat this week. > > > > I did not receive any answer from the authors to my review of this > > document as part of the security directorate review process, three > > weeks ago. > > > > Please consider my comments as formal COMMENTS in the IESG > > evaluation. > > > > And at the discretion of the AD: #2 and #4 could/should be seen as a > > DISCUSS. > > Tobias: Thanks for your time in reviewing the draft, and > apologies for not getting back to you earlier. We did get your > original review dated June 28th, but with business travel and other > summer plans, it was a bit of a logistical problem to have the > authors sync up on addressing your review until recently. As it > happens, I was about to send a reply to your review today. > > Your first comment was related to a spelling error; that will > be fixed. > > Your second comment was as follows: > > 2. section 4.3: I can not understand why this is a MAY and not at > > least a SHOULD (or MUST): Once the answerer has generated an answer > > following the ICE procedures, both user agents MAY perform the > > connectivity checks specified by ICE. > > > > Would recommend to use at least SHOULD instead of MAY in this > > statement. Maybe good would even be a MUST??? > > We've decided to reword that sentence as shown below. Because > we are mandating/recommending the use of ICE, we simply say do > what ICE wants you to do. > > OLD: > both user agents MAY perform the connectivity checks > specified by ICE. > > NEW: > both user agents perform the connectivity checks as > specified by ICE. > > The third comments was: > > 3. section 7 security consideration: > > > > This section refers to sec considerations in other documents, stating > > that those cover threats and countermeasures adequately, namely > > references [6], [7] and [2] > > > > [2] is ok, but [6] and [7] are still work in progress, so it must be > > especially taken care of by the WG chairs that both documents really > > fulfil this promise. With [7] this looks like near to fulfilment, but > > [6] still is not complete in its Security considerations section and > > must be improved in before LC to also keep up with the promise made > > in this document. > > [6] is the reference for STUN relay usage; yes, the v6-transition > draft will have to wait until the STUN relay usage draft has its > security consideration section flushed out in more detail. > > And the last comment was: > > 4. section 7: > > > > The section correctly informs about the risk that this draft > > > > "they may make hosts more amenable to existing threats. " > > > > And it provides an example afterwards. This is good. > > > > But I would expect or at least suggest to also provide information > > about how this risen risk should be countered. > > Fair enough; how about adding text along these lines: > > OLD: > Malicious user agents that may intercept the request > can mount a denial of service attack targeted to the different > network interfaces of the UAC. > > NEW: > Malicious user agents that may intercept the request > can mount a denial of service attack targeted to the different > network interfaces of the UAC. In such a case, the UAC > should use mechanisms that protects confidentiality and > integrity, such as TLS [add reference] or S/MIME [add reference]. > If HTTP Digest is used as an authentication mechanism in > SIP, then the UAC should ensure that the quality of protection > also includes the SDP payload. > > Please let us know if we were remiss in addressing any other > concern. And once again, apologies for the late reply. > > Best regards, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf