Vijay K. Gurbani wrote:
Paul Kyzivat wrote:
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.
Any way you cut, slice, and dice this thing, TCP connection reuse
in the backwards direction is bad. Note that it does not work with
virtual servers at all.
Unfortunately, people are using it and as such something ought to
be said about it in the draft. I agree that as the less said, the
better. I also agree that putting the "alias" parameter in the
Via request for TCP.
There seems to be something wrong with the last sentence. Did you forget
a word or two?
Going back to our scenario of A opening a connection to B, it
probably suffices to massage the text you proposed in an earlier
email of this thread:
B MUST NOT reuse this connection for requests to the
supposed party at the other end UNLESS it has some way
of verifying the identity of that party to the same level
of assurance as it would have by doing the DNS lookup and
establishing its own connection. For instance, if a DNS
lookup resolved to the same address and port as the source
port of the inbound connection then that ought be be good
enough.
I was thinking about that too. That "for instance" *seems* reasonable to
me, but I would like to hear what others think.
This still does not solve the problem of reusing TCP connections
for virtual servers; i.e., B does not know that that A's physical
IP address is being used by multiple virtual domains.
I don't understand what point you are making here.
Thanks,
Paul
Again, I
can just point this out for the TCP and SCTP transport in
the virtual server section more emphatically and leave it at that.
- 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
