Look, my question about security documentation for SIP extensions had
nothing to do with SIPSEC and everything to do with documenting the
current please-molest-me proxy-mediated transitive-faith-in-goodness
I-believe-my-operator-cares-for-me model of SIP security. And we DO
need to document this model better -- the question is how.
So I'm changing the thread subject for further discussion on SIPSEC.
On Aug 14, 2007, at 2:29 PM, Cullen Jennings wrote:
The other thing that I think is important is considering sipsec is
why is the proxy in the path in the first place? If the proxy does
not need to see or change any of the headers why is the message
traversing the proxy at all?
see draft-ietf-sip-outbound.
Outbound proxies do NOT really need to see or change any of the SIP
headers. But they're very, very useful from a NAT traversal perspective.
With SIPSEC, the outbound proxy sees CONNECT, routes it, then
establishes a packet-forwarding channel. The UAs do keepalive on this
channel. And everybody is happy and secure.
Of course, we could probably have done the same thing with STUN
relay, if we had a way to route STUN-relay requests or REGISTER
contacts containing vectors of STUN relays. But we don't, yet.
--
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
