Subject: Re: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05

From: [email-masked]
Date: Wed, 8 Aug 2007 14:20:57 -0400

From: Paul Kyzivat <[email-masked]>

   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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 8 Aug 2007 11:35:04 -0700

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-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 08, 2007 1:21 PM
To: [email-masked]
Subject: Re: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05

   In a way, this is similar the a loop that includes both a sip leg and
a
   PSTN leg.

Here is a first draft:

Dale