Jiri,  
I agree with you on the importance of the problem, but I don't agree
with you that we can solve the problem by changing one of the protocol
basics at this time, with millions of existing boxes, network boxes as
well as end devices. Especially the end devices are critical. Most of
them send today the IP-address in the call-ID. Customers often do not
accept the upgrades. Some customers also have their own boxes. It will
take at least 10 years until we can can rely on the secure call-id for
dialog correlation. This is far too late. We also do not realy know
which problems may occur if we change the protocol basics. 

I support the session-ID troubleshooting. It works fine and it works
now. For dialog matching we should work on a more general framework,
e.g. context-id or something else.

We can try secure call-id as a long term improvement of the protocol.
But we have to make sure that we do not cause problems for the existing
boxes and services which are up and running.       

 Laura


 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Jiri Kuthan
> Sent: Thursday, March 26, 2009 11:34 PM
> To: Hadriel Kaplan
> Cc: IETF SIP List
> Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00
> 
> First of all I think it is definitely worth trying.
> 
> Not being able to correlate dialogs through B2BUA is a big
> operational problem. I'm not sure that this will get really
> adopted (who knows what today's obfuscators choose to obfuscate
> tomorrow...). However in hope for solving this problem, presence of
> incentives for adoption and absence  of any known harm it is
> definitely worth doing.
> 
> Another idea how to accommodate receivers that are silly not
> to be liberal is using a fake IP address (popular 0.0.0.0).
> While not aesthetic at all, it could accommodate such receivers
> (under assumption they assign no syntactical meaning to it)
> and signal to B2BUA there is no disclosure of IP addresses.
> 
> OTOH it could be time too to abandon 2543 legacy. Supporting
> strict routing and other ancient stuff like IP in callid does
> not seem worth the trouble to me.
> 
> -jiri
> 
> Hadriel Kaplan wrote:
> > Ooh, good point.  Fair enough, I'll change that.
> > 
> > -hadriel
> > 
> >> -----Original Message-----
> >> From: [email protected] [mailto:[email protected]] 
> On Behalf Of
> >> Jonathan Rosenberg
> >> Sent: Wednesday, March 25, 2009 4:51 PM
> >> To: IETF SIP List
> >> Subject: [Sip] The problem with draft-kaplan-sip-secure-call-id-00
> >>
> >> I didnt get a chance to say this at the mike.
> >>
> >> You *cannot* change the BNF for the call-id. If you did, 
> you might end
> >> up with the following problem:
> >>
> >> A new UA gets built, compliant to this update. It is one of these
> >> 'aggressive parsing' UAs. It rejects any message which is 
> not compliant
> >> to the BNF. An older, normal RFC-3261 compliant UA sends a 
> call-id which
> >> includes the @-sign.
> >>
> >> According to the BNF of this updated 3261, and based on 
> the strictness
> >> of this aggressive-parsing UAs, it rejects that request as 
> non-compliant.
> >>
> >> As such, you need to keep the BNF, but change the 
> normative language
> >> such that an endpoint MUST NOT include the [@ host] but 
> MUST be prepared
> >> to receive it.
> >>
> >> -Jonathan R.
> >>
> >> --
> >> Jonathan D. Rosenberg, Ph.D.                   111 Wood 
> Avenue South
> >> Cisco Fellow                                   Iselin, NJ 08830
> >> Cisco, Voice Technology Group
> >> [email protected]
> >> http://www.jdrosen.net                         PHONE: 
> (408) 902-3084
> >> http://www.cisco.com
> >> _______________________________________________
> >> Sip mailing list  https://www.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://www.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://www.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://www.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

Reply via email to