[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] Receiver oriented signaling: (was: What good is SIPS:?)

It seems to me that SIPS has and has always had things completely wrong: it views this
from the perspective of the sender who has little or no control over the path that the
request is routed. About the only thing that a sender can do is say "Hey, I'd like this
to happen, but I'm at your mercy." Such is the cost of transitive trust.

What it seems to me is that we should not be viewing this from the standpoint of the
sender, but instead of the _receiver_ who ultimately should decide whether to accept or
reject a session -- and is probably in the best position to know the preferences of the
possibly human callee.

So instead of having a one-size-fits all approach, suppose that we just do a couple
of things:

1) Allow the originator to specify whether they'd like signaling confidentiality/integrity
along the path; this is NOT a demand, it is a "please".
2) Have the ability for each hop to label the level of confidentiality/integrity along the
path (eg, protect=[none|tls|ipsec|docsis|...])
3) The receiver inspects both the sender's hope, the protection afforded along the path
intersected with its local policies to determine whether to accept the session or not.
4) We have also have a BCP which says nice proxies/b2bua's send messages out
with as good if not better integrity/confidentialilty on the next hop

This of course doesn't eliminate the possibility of lying middle proxies, but it does
get rid of busy-body middle proxies who fail calls in ways that neither the sender
or receiver have very good control over. I mean, ultimately we'd like to give as much
control over the fate of the session to the end UA, right?

This would, for example, give receivers like a phone UA the ability to
determine that once it gets into its trust boundary, the necessity for TLS does not
compromise its policy, and that the sender shouldn't be alarmed if it's not encrypted
the entire way to the UA. Likewise, for a public PSTN gateway it might be of the
mind that what the heck -- I'm going to turn around and reformat these media/signaling
bits in the clear, so why should I bother consuming my resources on the previous
hop?

The point here is that there are a *substantial* number of scenarios that have very
different needs which are trying to be rolled up into the single "S" bit of SIPS. This
was a fairly reasonable thing with HTTPS since it is essentially always e2e. SIP
has always had a proxy routed architecture, and is thus far more complicated...

Mike, I have another idea, but I'll break that into a separate message

Dean Willis wrote:


What does sips: do for us?

It allows the end-user to ask the proxies to apply hop-by-hop cryptography and authentication, with the assurance that proxies that support the spec will honor that request.

It's not a high level of security as it says nothing about and cannot detect non-compliant proxies, but it is a property that we don't have with any other SIP mechanism at this time.

Many people believe this is a useful property despite its limitations. People are apparently trying to use it today, with inconsistent results. Francois' draft is intended to at least help them produce consistent results.

As we think about alternatives or changes in specification, let's keep that one useful property in-mind.

This leaves us with two questions, and we should try and differentiate further discussion by which question we're talking about:

1) Is it worth helping people get what they can out of SIPS: as roughly described in 3261, or is it so broken we should just suggest not bothering?


2) Do we need to do something beyond what sips:-as-per-RFC 3261 does, and if so, what properties does that something need to have? I personally suspect that there are three useful categories of "beyond":

a. Fix the last-hop exception and first-hop lack-of-exception, either by eliminating it/them or more clearly codifying what we're talking about.

    b. Clarify the usage for non-TLS alternatives, if any.

c. Provide an end-to-end alternative that is fully verifiable by the UAC (and maybe the UAS). Of course, this leaves open the question of what happens if either node is a B2BUA.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip