Paul Kyzivat wrote: > Hmm. Now that I think about this further, I am thinking that you can't > use the same TCP connection for the response without maintaining > state. > > Minimally, you need to maintain enough state to associate the response > with the connection. Without that, you can't decide to use the > connection for responses or other requests for the reasons that have > come up in the connection reuse draft. (It would provide an > opportunity for somebody to hyjack requests and responses.) >
For responses, it is possible to add information regarding the connection into the Via header of the request. You can e.g. include the remote port, and use that to lookup the connection in a table. If required, you can add an integrity mechanism to avoid hijacking (and maybe encryption). Although, the risk for responses does not appear high: a malicious downstream element could cause the response to be routed via the upstream host to a different system, but only to one that already has a connection with that host (and for which the attacker knows the remote port). Does not seem very useful Regards, Jeroen _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
