Hadriel Kaplan wrote:
True enough. (well... actually some proxies are digest challenged,
but they essentially act as UA's for that, and obviously it requires
a shared secret) I was just responding to Paul when he said B has no
way to authenticate A.
[...]
I think the disconnect is you're trying to say proxy A should police
the behavior of proxy B? Proxy B may or may not have a legitimate
reason for sending a request to proxy A on A's client TCP/TLS
connection.
Hadriel: The bottom line of your reasoning boils down to this:
If A opens up a TCP connection to B, and it has some policy such
that it considers B to be trusted, it MAY insert an alias parameter
in the topmost Via of that request. This will cause B to send
requests in the backwards direction over that connection.
Exactly what this policy is will be left up to each service
provider and implementation.
The draft can adequately warn implementations not to do so over
TCP due to various security reasons documented elsewhere in the
draft. The normative strength of reusing a TCP connection in
this manner could be left as a SHOULD, with strong incentives
to perform connection reuse only over TLS.
Would this be a working solution that will strike a middle-
ground? Is this agreeable to everyone else (Paul? others?)
sorry for sticking on this point, it's just that when
we get into debates with other vendors over interop issues in the
field, RFCs are the tie-breakers; and these seemingly innocuous
statements in RFCs often come back to bite us. :(
Funny -- so you have also been doing the frantic "RFC3261-dance-to-
support-my-argument (TM)" ;-)
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
