[secdir] SECDIR review of draft-worley-service-example-13

[Stephen Kent <[e-mail]>]

SECDIR review of draft-worley-service-example-13

I reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.These 
comments were written primarily for the benefit of the security area 
directors.Document editors and WG chairs should treat these comments 
just like any other last call comments.

This document describes how to provide music on old (MOH) in a VoIp 
environment, an obviously critical capability needed to preserve feature 
compatibility with the PSTN. Callers who are not subjected to MOH might 
otherwise not be exposed to classical music, in many contexts, a tragic 
outcome.

This document is intended to be Informational. The author notes that 
this status is appropriate because there are other methods for providing 
MOH, and they interoperate. He believes that the proposed method is 
superior, but not so much as to warrant BCP status.

The document seems to be well-written, clear, and it contains numerous 
examples (and diagrams) to help illustrate the mechanism details. I was 
surprised to see that all the references to RFCs (normative and 
informative) use labels other than RFC numbers. This an unusual 
convention that I hope the RFC editor will fix.

It is hard to overstate the importance of appropriate security 
mechanisms for this critical aspect of VoIP. Consistent with this 
observation, the Security Considerations section of this document 
consists of just one paragraph. The paragraph addresses one security 
concern, i.e., the ability of the UA of a caller to filter incoming 
media based on the address of the source of the media. The design in 
this document provides the source address of the MOH server, via SDP (in 
a re-INVITE), to the caller who is on hold, and thus satisfies this concern.

In a more serious vein, I'd like to see the Security Considerations 
section mention whether UAs are expected to use SDP and SIP security 
mechanisms for MOH, IF these mechanisms were employed for the original 
call. Another paragraph could be added to discuss the desirability of 
maintaining an equivalent level of security when a caller is switched 
over to MOH, and to cite the relevant RFCs, or to explain why this is 
not appropriate.