Subject: Re: [Sip] The Problem with PRACK

From: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 17:14:05 -0600

On Mar 15, 2006, at 4:45 PM, Brian Stucker wrote:
> . . .

> Seriously though, I don't think we can sit back and just say that  
> this is a badly designed service. These are real services that  
> exist in the real world that we all have to design and architect  
> for in the near term.

Sure we can. I'm fed up with being constrained by telecom-oriented  
preconceived notions and ending up with compromised security, broken  
implementations, and a headache that just won't quit. We can meet the  
critical end-user requirements (it just works!) much more effectively  
by tossing out badly designed services than by tossing out much- 
needed principles.

> Are you pushing for an RFC-2543 type revolution versus RFC-3261?

Very little in the way of protocol change is needed. We will  
eventually need to fix the "retargeting" design error that Jonathan  
noted in his route-construction draft, but we believe this can be  
done in a backward-compatible fashion. True, this does continue the  
correction of request-routing design errors in RFC 2543 that started  
with loose-routing in RFC 3261, but it's significantly less invasive.

But we do need an ARCHITECTURAL revolution. We must STOP thinking  
that we have a Class-5 switch controlling a bunch of call legs, and  
START thinking we have intelligent endpoints connected to the Internet.

> We also have many esteemed colleagues in 3GPP and 3GPP2 (amongst  
> other groups) as you well know that allow and rely on deep packet  
> inspection (like the P-CSCF and S-CSCF) with all sorts of service  
> and routing interactions to boot. It seemed like in your earlier  
> reply that you were suggesting that if a SIP proxy didn't change  
> anything in the message other than the request URI and did it more  
> than once that it should be a BBUA. Did I read you correctly?

Actually, I'd say that if a SIP proxy really needs to change the  
request URI (which is not the same as the request routing), then it  
needs to be a B2BUA. And that most cases where we THINK we need to  
change the request-URI can and should be accommodated by redirection.

As for our colleagues who have consistently violated Internet design  
principles in their architectures -- I'm sorry they did this. I tried  
to warn them. Perhaps I didn't try hard enough, or simply failed to  
communicate, and am guilty therefore of complicity. So hang me from  
the same tree.

But we have no requirement in the IETF to be constrained by their  
choices in designing a walled garden. Instead, we have a requirement  
to do the right thing for the Internet. And building services based  
on invisible mediators that preclude end-to-end transparency is NOT  
in the best interests of the Internet.

--
Dean

_______________________________________________
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: "Brian Stucker" <[email-masked]>
Date: Wed, 15 Mar 2006 16:45:48 -0600

I can see where this is headed... Deprecation of forking. :)

Seriously though, I don't think we can sit back and just say that this is a badly designed service. These are real services that exist in the real world that we all have to design and architect for in the near term. Are you pushing for an RFC-2543 type revolution versus RFC-3261?

We also have many esteemed colleagues in 3GPP and 3GPP2 (amongst other groups) as you well know that allow and rely on deep packet inspection (like the P-CSCF and S-CSCF) with all sorts of service and routing interactions to boot. It seemed like in your earlier reply that you were suggesting that if a SIP proxy didn't change anything in the message other than the request URI and did it more than once that it should be a BBUA. Did I read you correctly?

Regards,
Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, March 15, 2006 4:39 PM
To: Stucker, Brian [RICH1:B620:EXCH]
Cc: Michael Hammer (mhammer); Cullen Jennings (fluffy); [email-masked];
Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat (pkyzivat)
Subject: Re: [Sip] The Problem with PRACK

On Mar 15, 2006, at 11:38 AM, Brian Stucker wrote:

> I don't know that I follow you suggestion in the specific case I am  
> talking about.
>
> Take for instance Call Forward No Answer. In this case, A never  
> says that it's done with the call before it is retargeted to B by  
> the network. A and B have no idea that the service even exists in  
> the middle.

That's called a "badly designed service", from a security  
perspective. If the service can squat on the call, whats to prevent  
some other MITM?

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 16 Mar 2006 12:53:44 +0200

> I can see where this is headed... Deprecation of forking. :)

go ahead and you have nothing else left that mimic of PSTN over IP.  is
that all what SIP was going to be?

-- juha