I think Cullen was being facetious. Many of the hops along the path do not insert themselves purely to aid your UAC in finding the UAS. Otherwise they would mostly be stateless or redirect proxies. Obviously some do only that, but my guess is that's the exception not the rule.
[flame retardant enabled] There are all forms of stateful proxies (and more) along the path between a UAC and UAS, and I seriously doubt their owners are interested in removing them from it. Ignoring all the things boxes do these days, even from a "security" perspective many of their owners see it in the complete reverse model - the endpoints are about the least secure thing they can imagine. No way are they letting John Doe's softphone-de-jour at wildwest.com exchange SIP directly with one of their SIP subscribers, pstn gateways, voicemail servers, etc. Seems to me that sort of thing is a fine argument/use for p2psip. -hadriel > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 14, 2007 7:41 PM > To: Cullen Jennings > Cc: Matt Lepinski; sip List; Paul Kyzivat; Sandy Murphy > Subject: SIPSEC questions (Was Re: [Sip] Question on SIP > Securityconsiderations for future extensions) > > On Aug 14, 2007, at 2:29 PM, Cullen Jennings wrote: > > > > The other thing that I think is important is considering sipsec is > > why is the proxy in the path in the first place? If the proxy does > > not need to see or change any of the headers why is the message > > traversing the proxy at all? > > > > see draft-ietf-sip-outbound. > > Outbound proxies do NOT really need to see or change any of the SIP > headers. But they're very, very useful from a NAT traversal perspective. > > With SIPSEC, the outbound proxy sees CONNECT, routes it, then > establishes a packet-forwarding channel. The UAs do keepalive on this > channel. And everybody is happy and secure. > > Of course, we could probably have done the same thing with STUN > relay, if we had a way to route STUN-relay requests or REGISTER > contacts containing vectors of STUN relays. But we don't, yet. > > -- > Dean > > > _______________________________________________ > 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
