> -----Original Message----- > From: Robert Sparks [mailto:[EMAIL PROTECTED] > Sent: Monday, June 04, 2007 11:08 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; SIP IETF > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last > thoughts on transport=tls? > >
> > > > UAC -----> Proxy 1 ------> Proxy 2 ------> UAS > > How (if they don't have DNS) do they specify the use of TLS between > Proxy1 and 2? > More specifically - if Proxy1 retargets an initial request to > Proxy2 based on either > configuration or a registered contact, what's the RURI of > the emitted request going to be? > Then, what should it record route with? I'm not sure I understand what we are trying to achieve here. Say UAC sends initial INVITE. It chooses TLS for transport. No transport parameter. UAC does not use SIPS and therefore does not expect TLS on each hop. Proxy 1 forwards the request to proxy 2. If may or may not use TLS (although it should use TLS if possible). It inserts a Record-Route (or modifies Request-URI). In either cases, it does not need to put a transport parameter. Later, in-dialog request will be sent on each hop reusing the existing established connections (TLS or TCP) as per current RFC 3261 procedures. Or are we talking pass each other? > > 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. > > I don't understand the last sentence - especially in the > record-route/ route case. I'm just saying the first hop is whatever is selected when you sent the message. Since it's the first hop, there the parameter would be useless. > > > > 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. > > This is not what I'm pointing at. I'm trying to understand what you are pointing at. Is it in-dialog requests? Is it forcing a specific hop (not the first or last one) to be TLS, but not all the hops? I think I'm missing something... > > > >> 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. > > So the unusual case here is that it _is possible_ (and even > meaningful) for the proxy to open a new connection to the UA > if the old one is gone. Are you saying that you would like > the proxy/registrar to remember that it should use TLS when > it did so as a side-effect of the registration arriving over TLS? > > > That would be a way we could go (and we should go all the way > and ignore what's in contact altogether if we go here), but > you will have to explicitly make 3rd party registration and > any registration that installs state that doesn't point > exactly to the registering instance illegal. (I know several > people think this is a good idea, but I don't think we've > made that the official position of the working group yet have we?) I was not thinking specifically of the Mutual-TLS case which is what you are pointing to. In the server-provided certificate case, the client would be responsible to re-establish the TLS connection. The way to do this for server-provided certificate environments is using sip-outbound which does exactly what you said (i.e., ignore the contact). The the registrar doesn't "remember" anything: it just uses existing connections. I tought that was agreed (in Montreal). I don't see any other way to be honest. Now, you do bring up a really good point for environments where people use Mutual-TLS between a proxy and a UA. I guess we could still use an outbound model for this case. Or we could use some indication in the protocol. Not sure it's worth it to add a transport parameter for that. Seems to me to be overly complex, and it wouldn't allow you to indicate that you support many different transport. The third party registration case with the transport parameter is weird to me. It would allow a UA to send a Registration unseculily (over TCP or UDP), and create a binding for a third party using TLS. Seems like it would make the TLS connection pointless (unless somehow the first party is secure some other way). _______________________________________________ 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
