The attached is a good example of why the SBC is not only a repeat of the NAT problem, but much worse. Will there be an SBC WGs similar to the MIDCOM and BEHAVE WGs?
Or just brand the SBC as an Internet unfriendly device? One way around it is to make the IETF contributors read a "note well": We are here to implement and support the e2e principle and Internet transparency and not misuse the IETF resources for non-Internet network designs. Henry -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 08, 2007 1:21 PM To: [email protected] Subject: Re: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05 From: Paul Kyzivat <[EMAIL PROTECTED]> Yes, if the obfuscating proxy performs the loop checking based on its own Via. But if you have *two* obfuscating proxies in the loop then I think it becomes impossible to detect the loop. In a way, this is similar the a loop that includes both a sip leg and a PSTN leg. I don't have a good solution for either of these. I think that we can/should add a restriction to the text that is binding on "SBCs" to reduce the risks that they will unintentionally defeat loop-detection. Of course, that is inherently impossible, because the SBCs we are talking about are not proxies and don't have to follow any particular rules. But, IMHO, if we write a restriction that is workable, there will be some market pressure on SBC vendors "to be compliant with RFC xxxx" -- not to mention that we will give vendors some guidance on *how* to avoid defeating loop-detection, and I've discovered that even if it is "straightforward" that a problem exists and should be avoided, one cannot in general depend on software engineers to notice that without being told. Here is a first draft: For the purposes of this section, we define "SBC" as: A SIP agent (which may be a proxy or user agent) which primarily sends SIP requests and responses in reaction to receiving similar SIP requests and responses. An SBC is said to be conformant to this specification if, in any expected deployment, the universe of all SIP agents will be divided into a number of sets, which we call "regions", and each region possesses at least one of the following loop-detection properties: A) if all of the agents in the region are assumed to implement this RFC, no propagating chain of requests can pass through the same SIP agent in the region twice with the same routing information without being detected by the mechanism of this RFC (even if the chain passes through other regions in the meantime), B) a propagating chain of requests can never enter the region more than once from any other region while containig the same routing information, due to cooperation by the SIP agents in the region containing the SBC (by a mechanism outside the scope of this RFC), or C) the administrator of the SBC has positive knowledge that the technical and/or administrative configuration of the SIP agents in the region ensures that if a request enters the same SIP agent twice with the same routing information that it will be rejected as a looped request (by a mechanism outside the scope of this RFC). Normally, an SBC (and its redundant cohorts) will divide the universe into three regions: the SBC and its cohorts, the network "inside" that they protect, and the public Internet. There seem to be three ways to prevent loops within any region: (A) assume they implement loop-detection, and require the SBC to propagate the loop-detection information in requests when they enter/leave the region, (B) have the SBCs do it somehow, or (C) *know* that the SIP agents in the region implement some other form of loop detection. I would particularly like to know what SBC vendors think of this. Dale _______________________________________________ Sip mailing list https://www1.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 _______________________________________________ Sip mailing list https://www1.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
