Subject: RE: [Sip] The Problem with PRACK

From: "Brian Stucker" <[email-masked]>
Date: Wed, 15 Mar 2006 17:28:34 -0600

Well said.

I think you may be assuming that I'm thinking only in terms of a class-5 switch in the middle. I'm not. I'm also thinking of cases where you have a simple proxy acting as an application layer router alone because for reasons of privacy, clean call logic separation between the originating and terminating party, and possibly network topology or security issues the redirection cannot easily be done directly by the client initiating the call.

With redirection, I see these problems being solved with a "come back to me again with a new request URI" list and some other meta-data that describes timers, etc. The request URI may be obsfucated in a manner that the routing privacy of the terminator is preserved, and by going back through the proxy you get around the network topology issues. However, I'm left with the increased messaging and non-separation of the orig and term call models.

Leaving DPI aside and focusing on this, any thoughts?

Regards,
Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, March 15, 2006 5:14 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 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: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 17:49:05 -0600

> Well said.

Thanks.

> I think you may be assuming that I'm thinking only in terms of a  
> class-5 switch in the middle. I'm not. I'm also thinking of cases  
> where you have a simple proxy acting as an application layer router  
> alone because for reasons of privacy, clean call logic separation  
> between the originating and terminating party, and possibly network  
> topology or security issues the redirection cannot easily be done  
> directly by the client initiating the call.
>
> With redirection, I see these problems being solved with a "come  
> back to me again with a new request URI" list and some other meta- 
> data that describes timers, etc. The request URI may be obsfucated  
> in a manner that the routing privacy of the terminator is  
> preserved, and by going back through the proxy you get around the  
> network topology issues. However, I'm left with the increased  
> messaging and non-separation of the orig and term call models.
>

Yep. When you REALLY need that sort of obfuscation, you might really  
need a B2BUA, with media relay, and not  a proxy service. If you're  
willing to reveal the actual endpoint's contact (which might be  
ephemeral), then redirection is adequate.

And why should we have a separation of call models? Why should we  
even HAVE a "call model", as that is very much a PSTN term as it is  
usually applied?

--
Dean

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Wed, 15 Mar 2006 17:53:52 -0600

Hello,

This has been a long chat. Can someone please summarize where we are at?

Sorry for not reading all mails.

Cheers,

Martin

> Sent: Wednesday, March 15, 2006 6:49 PM
> To: Brian Stucker
> Cc: Cullen Jennings (fluffy); [email-masked]; Francois Audet; 
> Paul Kyzivat
> (pkyzivat)

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 18:06:44 -0600

> This has been a long chat. Can someone please summarize where we  

Lost and wandering in the desert?

> Sorry for not reading all mails.

Seriously, we've hit a couple of salient points.

1) PRACK is convoluted. It might can be simplified. Or maybe, we  
don't need it at all. We' have one thread discussing the requirements  
for and alternatives to preconditions.

2) Proxy retargeting remains "bad" and hop-by-hop TLS is  
questionable. That spun off a new thread on cryptotransparency at  
proxies, and a related thread on cryptoparticipant service models  
(including redirect) though the main PRACK thread occasionally raised  
arguments relevant to to this second discussion.

3) Slavish re-creation of PSTN service-switching modalities without  
regard to the practical realities of the Internet is a Really Bad Idea.

--
Dean

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Wed, 15 Mar 2006 18:41:44 -0600

Always the sobering voice....

> Sent: Wednesday, March 15, 2006 7:07 PM
> To: Dolly, Martin C, ALABS
> Cc: Brian Stucker; Cullen Jennings (fluffy); [email-masked]; Francois
> Audet; Paul Kyzivat (pkyzivat)

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 15 Mar 2006 20:35:43 -0500

I've updated the PING draft:

draft-fwmiller-ping-02

http://www.cornfed.com/ping.txt
http://www.cornfed.com/ping.html

I made two changes.  First, I took out the verbage about no
retransmissions.  A PING request initiates a standard NIT as before.  I
went back and looked at the NIT client side again and found that the max
interval during requests retransmissions is actually 4 seconds.  This
means that the concern that a NAT binding might drop is unfounded if the
stated assumption of 15 seconds is valid.

Second, I added a paragraph on the potential expedited processing at the
UAS that has been suggested.

I'm also uploading the .txt version to the IETF side tonight.

Thanks,
FM