Bruce,
Thanks for your response. Clearly there's lots to discuss in these
topics. I have a comment relating to two of your responses.
Thanks,
Alan
Bruce Lowekamp wrote:
<snip>
deployments. Also, there is an open issue about what layer this
interacts with SIP, and whether a new SIP transport token needs to be
defined.
Since the current draft does not specify tunneling SIP over the
overlay, no new tokens are needed at this time.
<snip>
3. There is still a major security flaw relating to SIPS.
I don't think I need to repeat myself on this one. If I am incorrect
that a SIPS (or any SIP message sent over TLS) sent using the Tunnel
method would not be transported confidentially over the overlay, then
please let me know. Otherwise, fixing this before WGLC would seem
like a good idea.
The current draft does not specify sending SIP messages through
tunnels. Such a specification would absolutely have to address that
issue.
I am very surprised by the removal of this. Was this just done to avoid
dealing with the security and transport issues or was it felt that there
was no value in it?
If we are unable to route SIP messages over the overlay, then the
overlay is effectively not providing a last resort rendezvous
functionality that we have with CS SIP.
So the only alternative seems to be for every peer to reserve and use
TURN candidates every time a SIP connection is established. Otherwise,
in the perhaps 15% of cases where a relay is needed, the SIP connection
will fail.
I'm very concerned that we have not fully thought through this usage of
TURN for both SIP and media...
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
