Francois Audet wrote:
No, that's not at all the main reason. RFC4474 is already
not end-to-end. It's signed by a middlebox in the
originating domain, and verified by a middlebox in the
terminating domain. There is ample opportunity to change the
SDP at either of those domains to perform lawful intercept.
End-to-end means from end domain to end domain. So 4474 is
end-to-end.
Again, if enterprise A wants to talk to enterprise B, without
some service provider spying or redirecting media for their
own potentially nefarious purposes, then 4474 is a perfect
way to ensure that you are talking to who you think you are
talking to.
The fact that these enterprise may or may not be using their
own SBCs to deal with NAT traversal and topology hiding is
not relevant.
The main reason to change SDP is to steer the media, for
numerous reasons.
It should be up to the Enterprise to decide if it is willing
to deal with a man-in-the-middle. If it does not, then it
can use 4474.
If it does, then it's not end-to-end security. This is probably
acceptable to many enterprises, provided that they can trust
their service provider.
So again, perhaps what we need is a non end-to-end secure identity.
Perhaps something that requires a broker/service provider.
I think that there is a lot of confusion around putting together
identity and integrity. It is not that I must have one for the other.
I can have identity without integrity of SDP and still be in position
to accept/decline a call based on who is calling me. If I'm worried
about media confidentiality, I can add zRTP.
As long as identity remains clearly separated from other stuff, we can
do quite some things. Most of the confusion seems to come from packaging
it with other functionalities. 4474 without integrity of the IP:port
in SDP would work, DERIVE (as e2e representaive) would work, certainly
many other things as well.
Let's face it, integrity of whole SDP payload is illusive and any
functionality relying upon it undeployable.
-jiri
_______________________________________________
Sip mailing list https://www.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
