The general concept is fine. I haven't checked whether the items that go into your hash include all the items recommended by the RFC(s), but you can check that yourself.
One difficulty is whether the items in the hash are everything that is "significant" about the call, that is, that could change how the call is routed. In principle, the proxy could examine some header field and sent it to some other proxy for modification, and after that is done, the request returns to your proxy, which will route it elsewhere now, even though the request-URI is the same. Worse, it is possible that some other proxy in your universe is making decisions based on that other header field. If this becomes troublesome, you need to include the other header field value in the hash. RFC 5393 gives some guidance: This second part MUST vary with any field used by the location service logic in determining where to retarget or forward this request. This is necessary to distinguish looped requests from spirals by allowing the proxy to recognize if none of the values affecting the processing of the request have changed. Hence, the second part MUST depend at least on the received Request-URI and any Route header field values used when processing the received request. Implementers need to take care to include all fields used by the location service logic in that particular implementation. You need to compare the computed antiloop_id value with *all* the Via headers in the requests, because the request may have cycled through another proxy since the last time it passed through this proxy. You don't need to include the Call-Id in the antiloop_id, because you will only be comparing antiloop_id values that were computed from messages that have the same Call-Id (various instances of some one request). Dale ________________________________________ From: [email protected] [[email protected]] On Behalf Of Iñaki Baz Castillo [[email protected]] Sent: Monday, November 28, 2011 9:11 AM To: [email protected] Subject: [Sip-implementors] Proxy loop detection implementation 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
