Paul Kyzivat wrote:
I like the direction this is headed. I have a few questions and observations:
Paul: Thanks much for reading the draft. More inline.
There seem to be some constraints for support of sipsec that I didn't see mentioned explicitly: - The UAC and each proxy must ensure that the transport used for the next hop is a connection-oriented, congestion-controlled transport. That is mentioned in the overview, but not specifically for the UAC and Proxy.
Right; modeling it on HTTP implicitly implied a congestion-controlled transport. With DTLS now in mix, one could conceivably consider using a connectionless transport with similar security properties as well. But at least right now, we're only considering congestion controlled transports.
- For the tunneling to work I don't think there can be shared use of the connection. That is something special here. (In case of SCTP, I guess it would be sufficient to reserve a stream.)
Right; in the default case, since the properties of the connection are tied to the certificates of the endpoints at each side, sharing a connection would appear to be problematic. Now, one use case for sharing could be a pair of user agents that serve a lot of users (gateways, for instance.) One could conceivably consider requests for different ports to be sent over the same tunnel. But this is not a specific scenario we had envisioned as a reason for the draft.
There are some things that is is desirable to do that may be hard with sipsec, or at least need to be figured out. A couple that come to mind are: - best effort security - forking For best effort security, one option seems to be to delay the CONNECT until you know the capabilities of the callee. For instance, a session could be established with SIP or SIPS, including supported:sipsec. If the session is established, then it could be followed up with a CONNECT/Replaces.
The problem with this approach would be that privacy is violated in the session that is established before the CONNECT request; even when h-b-h sips is used.
If you want to call an AOR that results in forking, CONNECT doesn't seem to work very well. I This may be a good reason to replace forking at a proxy with redirect. The proxy could return 3xx with the alternatives, which might be either SIP, SIPS, or SIPSEC. There are a lot of details to work our for this.
Right; agree. Forking is problematic. One way is to force the issue with rfc3841's Request-Disposition header. But that header elicits a normative strength of SHOULD in the proxies, thereby lending it an advisory mode only. Another way is to discourage forking for CONNECT in the draft, but allow for it to occur and simply accept the first 200 OK, closing the connection on subsequent ones. Clearly something that needs to be worked out in the draft going forward. Thanks. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ 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
