I think much less should be said.
Don't say that A must reject requests sent to it over the connection.
But also don't specify, or even imply, a mechanism by which B might
decide it is ok to send requests on this connection. And I think the
Alias is bad because it implies such a mechanism.
Vijay K. Gurbani wrote:
Paul Kyzivat wrote:
We have a lot of history of people taking carefully phrased things
like this and using them to justify a lot of incorrect behavior. We
don't want this to be misconstrued.
Paul, Hadriel: So ... where do we stand on this? It appears that
Digest challenge for proxies is a non-starter. Yesterday, I
had suggested something along these lines:
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.
As Hadriel pointed out, there is no issue of trust on the part of A.
(Were A to get a request over this connection that was addressed to A it
would have no more reason to distrust it than if it got the same request
over some other connection.) So the above is a sort of red herring.
The issue of trust is with B. A passing an alias parameter doesn't give
B any reason to believe the connection is really with A.
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.
The above seems ok to me.
This, of course, means that there is connection reuse in TCP
as well (i.e., using one TCP stream), but is not encouraged by
the draft, and implementations doing so will have adequately
weighed in the associated risks before doing so.
I can almost buy not *banning* it. But that is not the same as actually
having it in the draft.
Paul
Would this be a working solution that will strike a middle-
ground? Is this agreeable?
Thanks,
- vijay
_______________________________________________
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
