On Aug 14, 2009, at 9:31 AM, Olle E. Johansson wrote:
13 aug 2009 kl. 23.12 skrev Dean Willis:
Hmm. Could it be that since SIPS (draft-ietf-siip-sips) requires
e2e TLS even more strongly than did 3261 for original sips URIs. So
if a URI used in a record-route resolves both TLS and non-TLS,
there's a possibility that the return stroke might not use TLS,
thereby breaking the e2e TLS requirement. But your proposed wording
change seems to have the same effect.
I did not read the draft as SIPS requiring e2e TLS. We still use
proxys and have clear communication within the proxy. E2E to me is
UAC -> UAS with encryption ALL the way and no middleman.
Did I misunderstand?
It kind of on what you mean by "end to end". Draft-ietf-sip-sips
requires that TLS be used on every hop whenever a SIPS URI is used,
whereas RFC 3261 allowed an exemption for the "last hop". In the
language of the discussion at the time, this was considered "end to
end TLS" even though it wasn't "UA to UA TLS".
Under 3261, one could legitimately double record route at a proxy
performing contact routing with a first route entry having a SIPS URI
and a second having a SIP URI.
With draft-ietf-sip-sips, that behavior is forbidden if the result
would be to fail to use TLS on the route-segment indicated with a SIPS
URI.
The record-route-fix document is essentially promoting a very special
exception by noting that it is possible to construct a SIP URI such
that resolution of the SIP URI using the procedures of RFC 3263 would
guarantee that TLS is used, even though the URI itself is SIP instead
of SIPS.
Consequently, the working I suggested was intended to convey the idea
that the "special SIP URI" MUST resolve only to TLS and MUST NOT
resolve to a hop that would not use TLS, since the only case in which
we RFC 3261 would have allowed us to not use TLS was deprecated by
draft-ietf-sip-sips.
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implement...@cs.columbia.edu for questions on current sip
Use sipp...@ietf.org for new developments on the application of sip
