I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-sip-media-security-requirements-07.txt
Reviewer: Elwyn Davies
Review Date: 10 October 2008
IETF LC End Date: 13 October 2008
IESG Telechat date: (if known) -
Summary:
This document is almost ready for the IESG. I have a couple of comments
and queries about the reasoning in a few of the requirements.
Meta-comment: To a non-SIPper the problems to be solved and the
requirements look very challenging! And to think S in SIP might once
have meant...
Disclaimer: Whilst the requirements appear sensible and internally
consistent, I have no idea if the set is complete or really appropriate.
The explanations in s4 are very helpful and clear for a naive reader
like me. Likewise, I do not have the necessary knowledge to verify the
statements in the various appendices relating to existing proposals.
Again they look reasonable sensible.
Comments:
s5.1, Requirement R-RTP-VALID: I think some explanation of why '...the key
negotiation packets MUST NOT pass the RTP validity check
defined in Appendix A.1 of [RFC3550].' would help. This looks
like a magic incantation to me at present!
s5.1, Requirement R-NEGOTIATE: 'The media security key management
protocol MUST allow a SIP
User Agent to negotiate media security parameters for each
individual session.' Does this imply that the protocol MAY
allow the SIP UA to use the same parameters for several sessiosn if it
wants to? Might be wise to be explicit.. but I may not understand the
situation.
s5.2, Requirement R-FIPS: Whilst I know that the FIPS process is often
cited other than in the US, this requirement appears very US centric.
Are there other similar requirements from other countries that ought to
be considered?
s5.2, Requirement R-DOS: Whilst I know that it is probably impossible
to guarantee that a given solution will not introduce some arcane DOS
opportunity that no one has thought of, it seems to me that 'MUST NOT
introduce any foreseeable (or, maybe, significant) new DoS
vulnerabilities' would be better than SHOULD NOT, which allows for
possible weaseling.
Nits:
s4.2, last line on p.9: s/ares/are/
sA.5.4, MIKEY-NULL bullet: s/computaional/computational/
idnits reports:
draft-ietf-sip-media-security-requirements-07.txt(1166): Line has weird
spacing: '...ication along...'
Several references are now at later versions and
draft-ietf-msec-mikey-applicability has been published as RFC 5197.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf