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