I have seen cases where transport=tls appears in the Record-Route where one
hop between proxies uses TLS. For example:
UAC--<TCP>-->Proxy1---<TLS>--->Proxy2--<TCP>--->Proxy3---<TCP>-->UAS
This is done using a SIP URI (not SIPS).
I have not been able to keep up with this discussion, but the question I
have is: without transport=tls, how would you express the desire/need to do
TLS for a SIP URI in a Record-Route or Route header? I am talking about a
case where the proxy (Proxy2 above) supports TCP and TLS, but the selection
of transport is made for the initial INVITE, and that same transport needs
to be used for in-dialog requests?
cheers,
(-:bob
Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[EMAIL PROTECTED]
----- Original Message -----
From: "Francois Audet" <[EMAIL PROTECTED]>
To: "Robert Sparks" <[EMAIL PROTECTED]>; "Dean Willis"
<[EMAIL PROTECTED]>
Cc: "SIP IETF" <[email protected]>
Sent: Monday, June 04, 2007 1:28 PM
Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts
ontransport=tls?
1) Some still have to operate in an environment that has no
DNS, even in the core.
Their customers are demanding transport=tls to control
the use of tls over one hop in this situation.
Which hop???
UAC -----> Proxy 1 ------> Proxy 2 ------> UAS
If you put Request-URI of sip:[EMAIL PROTECTED];transport=tls, to me, it
means the link between Proxy 2 and UAS would use TLS. I.e., the
parameter would apply to the
resource identified in the URI. (I'm assuming Record-Routing is used
here).
The first hop (between UAC and Proxy 1) is basically what you would
select before sending the message (or if a Route header was used, it
would be in the Route
header). To me, it's self-evident in the actual transport anyways.
Everytime I run into this issue, it seems to me that basically what
people
are asking for is just a way to select TLS for the first hop. We don't
need
protocol on the wire for this: just a config option in the UAC.
2) Some have indicated they operate in large enterprise-like
networks, where the endpoint has an ephemeral address,
one for which there's no way to populate NAPTR/SRVs to
indicate a use of TLS when reaching that endpoint.
Additionally, the endpoint has a cert (!). They are
required to register a contact that causes them to be reached
with TLS, and are using transport=tls to do so.
Surely they need to register with TLS for this to be secure.
The transport could be self-evident again, from the one used
while performing the registration.
_______________________________________________
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
_______________________________________________
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
