Hi, following guidelines in RFC 3261 and RFC 5393 I've coded a loop detection in my proxy. Note however that my proxy does not fork so I don't need the Max-Breadth mechanism in RFC 5393.
It works as follows: - Then let's suppose that the request is made by an attacker and has a Request URI pointing to a domain "loop.hacker.org" which points to myproxy itself (but my proxy is not aware of such domain as it has been created by an attacker). Such a request is sent to my proxy. - The proxy takes a constant ANTILOOP_ID value (which is randomly generated upon server start), the Request URI, the top Route URI (if present) and the Call-ID, and makes a MD5 string (32 char length). That value is stored as "antiloop_id" value. - The proxy compares such "antiloop_id" value with the last 32 chars of the Via branch in the received request. They don't match so it's not a loop. - Then the proxy resolves the destination and creates a client transaction. The Via branch value is a random value followed by the "antiloop_id" value generated previously. - The request is then routed based on the Request URI (no Route header) so it comes again to the proxy. - This time, the proxy computes again the new "antiloop_id" value and compares it with the last 32 chars of the Via branch in the received request. They match so this is a loop and the request is rejected with 482 "Loop Detected". I've made several tests and it works fine, but I would like to know if there could be some drawback in this loop detection design. Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
