On Nov 8, 2007, at 7:48 AM, Joel M. Halpern wrote:
...
Do folks read either R24 or some other requirement as mandating
that the
IETF standardize an LI supporting solution?
No requirement can mandate that the IETF standardize an LI solution
(since we just can't and won't do that). The requirements draft is
being revised to describe the related requirements as external to the
IETF.
Our proposed response to their requirements is to say "With SRTP/
DTLS, the endpoints have the keys. If you want it, you have to ask
them for it. Here's one approach that you might use to do this. We
may use this same approach to allow recording."
The other alternative is that we do not explain this in the response.
Then it's either up to them to figure out how to ask for the keys
(which they can quite well do without us), or to instead use a
different key negotiation mechanism (such as S-Descriptions). Either
way, LI is still going to occur. It'll just do so in a manner that
doesn't interoperate with IETF-standard nodes. And it will cause the
mobile/regulated community to start writing their own private, not-
necessarily-publicly documented extensions to or "profiles of" IETF
protocols, which is something we've been trying to avoid. This might
all be acceptable, but we need to understand the consequences.
...
There was some mention that the media recording requirement is
relevant
to LI. By my reading, that is an end-point recording capability
requirement that we want to have. I doubt that the operators would
consider "ask the customer for the recording" an acceptable LI
mechanism.
I'd say that under RFC 1984 a mechanism whereby they can ask the
customer to allow them to record is the most we can give them. It's
up to them as to whether their policy allows calls to proceed in the
absence of that permission.
And asking the customer for the key on every call is clearly a
non-starter as a real-world solution to any of this.
Please explain the preceding.
Would the proposal not work?
Would the proposal have too much overhead to be cost-effective? It's
got less overhead than the alternative of including (for every call)
one or more media relays that act as SRTP/DTLS endpoints, maintain
two session keys per session, and decrypt/re-encrypt every packet. It
has slightly more overhead than sending the media session key along
the SIP path. It's also slightly more secure than sending the media
session key along the SIP path.
Would the proposal fail to inform the user about the security
constraints? From my POV, it is better for a user to say "Oh, I see
this call is being routed over a regulated network, so the service
provider and anybody they give the session key to can listen in"
rather than to say "Oh, this call is being routed over a regulated
network, and therefore I cannot use use any cryptography at all and
anybody who can sniff my 802.11 packets can listen in."
What makes it a non-starter?
--
Dean
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
