On Fri, 2009-03-06 at 12:52 -0500, Hadriel Kaplan wrote: > I appreciate that doing troubleshooting of SIP in SIP is very > appealing, but I'm worried about it. There are some real security > issues with this, even if we don't want to admit it. The reality is > that if this trace mechanism is actually adopted by any sizeable > measure, then middleboxes will be forced to munge the messages more > than they already do, to prevent it from being used/work. In other > words it's a self-defeating mechanism.
Yes, there should be a mechanism so that a transit network can make itself appear to be a wire, to be one hop, with regard to the trace mechanism. But there is no reason that the routing on the *far side* of a transit network should be hidden from the UAC -- at least, from the point of view of the transit network, the far-end network might have policies. (I'm envisioning a world in which the UAC's end may be involved in complex service provisioning in which there may be more than one transit network and more than one element that provides complex call routing. Though a transit network should be able to hide its internal structure, the UAC has the right to know what element the transit network delivered the request to, since that is what the UAC is paying the transit network to do.) > Today you can do incrementing Max-Forwards traceroute, similar to the > ICMP traceroute TTL trick, and even that's gotten some folks worried > enough to make us munge the Max-Forwards value (despite the obvious > dangers in doing so). But anyway why isn't that type of trace enough > for your needs? I envision sending 20 INVITEs to the same request-URI, with gradually increasing Max-Forwards values. Any UAS that can be reached in less than the maximum number of hops will get hammered. And, as you say, SBCs are already trying to prevent that. > Also, a couple specific questions/comments regarding this draft: > > 1) You use the term "final response" a couple times as being sent in > the 170's body. How would a final response be sent in a 170 response, > since the 170 would be before a final response? Clearly, the 170 would have to be formulated after the final response is formulated. But I don't see any particular prohibition on that, and there isn't any real restriction in the order that responses are sent. > 2) You state that a UAC should not create an early-dialog for the 170, > but for any B2BUA in the path which did not know about this new trace > mechanism, wouldn't it create early dialogs on the b2bua since it > would treat it as a 183? I suppose it would. Which would be somewhat resource-inefficient. But I don't expect the fraction of requests that are traced to be over 0.1%, so it shouldn't be a problem in practice. Dale _______________________________________________ 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
