Hi Dale, On Fri, Feb 20, 2009 at 10:24 PM, Dale Worley <[email protected]> wrote:
> Actually, the cookie isn't needed to validate where the request comes > from, but only to validate where the response will be sent. This allows > us to escape the requirement for symmetric signaling described above -- > cookies are generated based on the *destination* of the 4XX, and are > validated against the *response destination address* not the *request > source address*. This still has the required security property -- the > client can only obtain the cookie for a destination D if D cooperates in > capturing the cookie and providing it to the client. This does render > unusable the clause "If this fails...", because the client has to know > absolutely what the response destination will be. This actually seems like a far better way, althoguh the original reasoning was to handle the (all be it pathological) case of different stacks running on the same IP address but a different port as visible by a proxy - perhaps for example due to (argh!) CGNAT e.g on most mobile networks (at least in the UK) , or a serviced office which does NAT to the same external IP for all it's hosts. saying that, i'm not too fussed either way, and would appreciate any thoughts on it... > (Or can the requester provide multiple cookies for multiple possible > destinations?) I did consider this previously, but can'y see any way of being able to handle the case where sent-by contains a host name which resolves to multiple SRV records with same priority, as the response could go to any of them (and each would need to be validated and get it's own token) before passing it to the client to include in the request. cookies would also need to have a minimum lifetime, so that a server knows how long those it's generated are valid, and the whole thing becomes horribly complex... :-) my thinking was along the lines of because the response is going to be UDP, a server that needs the redundancy can use anycast on the single IP / port to ensure to gets the response, even if a given proxy (or even data centre) dies. ~ theo _______________________________________________ Sip mailing list https://www.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
