Subject: RE: [Sip] Additional uses of INFO

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 22 Jun 2006 19:24:00 -0400

Mike,

Has anyone ever put all the keying mechanisms for TLS or IPSEC into any
security protocol stack?

You know all that combinatoric stuff?  :)

Mike H

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Thursday, June 22, 2006 6:14 PM
> To: Dean Willis
> Cc: [email-masked]
> Subject: Re: [Sip] Additional uses of INFO
> 
> Dean Willis wrote:
> 
> >
> > On Jun 22, 2006, at 12:44 PM, Jonathan Rosenberg wrote:
> >
> >> This whole argument is based on the model that a new method is 
> >> somehow a  big change in SIP, whereas a new body is a 
> small one.  Why 
> >> is that?
> >>
> >
> > because it is true?
> >
> > The bodies are normally processed in code external to the 
> SIP stack, 
> > whereas methods are processed in the SIP stack itself.
> >
> > Again, I'd like to resort to "HTTP as a model". It's not incredibly 
> > clean, but it has had some successes.
> 
> So it's your position that you'd like SIP to be a generic 
> transport protocol which is what HTTP has become (from the 
> expected to the grotesque)? Versus being a redezvous protocol 
> which leads to the transport with some other protocol like, 
> oh say, HTTP?
> 
> I guess what I find weird about SIP's collapse into a 
> transport protocol for anything and everything is that it's 
> got all of this heavy proxy machinery, forking and all kinds 
> of other stuff for its primary job which leaves it pretty 
> suboptimal for a whole variety of reasons, not the least of 
> which is the inherent security issues of content through 3rd 
> parties whose intentions are dubious.
> 
> That and SIP's complexity has long since spiralled out of 
> control. It seems to me that HTTP gets by pretty well because 
> it doesn't attempt to be the last word on signaling 
> protocols. But SIP signals a lot of different things for a 
> lot of different purposes, and instead of getting relatively 
> light weight signaling with heavy weight content (HTTP), 
> going where you're suggesting would get you heavy weight 
> signaling with heavy weight content -- and the inherent combinatorics.
> 
> Last parting shot: I once asked Cullen whether anybody had 
> ever implemented all of the SIP RFC's into a single stack. As 
> I recall, he just laughed. Let's suppose that somebody were 
> so inclined to do so, would it have any prayer of being 
> passably self-consistent? Or dare I say work, FSVO work? What 
> does this say, especially in light of your position?
> 
>        Mike
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Eric Rescorla <[email-masked]>
Date: Thu, 22 Jun 2006 16:38:21 -0700

> You know all that combinatoric stuff?  :)

Actually, I believe that all of the standardized keying mechanisms
for TLS have been implemented in OpenSSL.

-Ekr