This is a good point. I'm sure some creativity here could be used to
tighten this up. The key point is that the stateless proxy needs to do
some work to associate responses with connections, and the way of doing
this need not be standardized.
Paul
Jeroen van Bemmel wrote:
> 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
