Subject: [Sip] The problem with draft-kaplan-sip-secure-call-id-00

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Mar 2009 16:51:15 -0400

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-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 25 Mar 2009 17:05:24 -0400

Ooh, good point.  Fair enough, I'll change that.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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
> 
> _______________________________________________
> Sip mailing list  https://www.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: "Spencer Dawkins" <[email-masked]>
Date: Wed, 25 Mar 2009 16:20:39 -0500

I agree with Jonathan - this is the right way to go.

Spencer

---

From: Venkatesh <[email-masked]>
Date: Wed, 25 Mar 2009 14:34:36 -0700

Hello:

I am not sure that this alone will fix the problem in totality. If I were to
use the reverse analogy i.e. what if a UA that conforms to this
specification offers the request to a "aggressive parsing" UA that is only
compliant with RFC 3261?
If we are not planning on changing the BNF, I am wondering if this draft
should simply say that the string after the "@" sign MUST NOT include a
domain name, host address, MAC....? Or if this is ambiguous, simply say that
the UA MUST generate *another* cryptographic identifier to be placed after
the @ sign?

Thanks,
Venkatesh

On Wed, Mar 25, 2009 at 1:51 PM, Jonathan Rosenberg <[email-masked]>wrote:

> You *cannot* change the BNF for the call-id. If you did, you might end up
> with the following problem:
>
> '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.
>
> --

---

From: Victor Pascual Ávila <[email-masked]>
Date: Wed, 25 Mar 2009 22:40:13 +0100

On Wed, Mar 25, 2009 at 10:34 PM, Venkatesh <[email-masked]> wrote:
(snip)
> the UA MUST generate *another* cryptographic identifier to be placed after

This would be fair enough.
-- 
Victor Pascual Ávila

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 25 Mar 2009 22:39:41 -0400

RFC 3261 made the @ and after it optional in ABNF.  So a strict parser to 3261 must allow it.  In fact we've seen plenty of Call-ID's without it, from some very common equipment.
We just can't change the BNF because a strict parser parsing to this new draft would not accept 3261 call-id's.
-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Venkatesh
Sent: Wednesday, March 25, 2009 5:35 PM
To: Jonathan Rosenberg
Cc: IETF SIP List
Subject: Re: [Sip] The problem with draft-kaplan-sip-secure-call-id-00

Hello:

I am not sure that this alone will fix the problem in totality. If I were to use the reverse analogy i.e. what if a UA that conforms to this specification offers the request to a "aggressive parsing" UA that is only compliant with RFC 3261?

If we are not planning on changing the BNF, I am wondering if this draft should simply say that the string after the "@" sign MUST NOT include a domain name, host address, MAC....? Or if this is ambiguous, simply say that the UA MUST generate *another* cryptographic identifier to be placed after the @ sign?

Thanks,
Venkatesh
On Wed, Mar 25, 2009 at 1:51 PM, Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>> wrote:
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-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]> for questions on current sip
Use [email-masked]<mailto:[email-masked]> for new developments on the application of sip

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 26 Mar 2009 23:34:28 +0100

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

---

From: <[email-masked]>
Date: Fri, 27 Mar 2009 18:13:29 +0100

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

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jiri Kuthan
> Sent: Thursday, March 26, 2009 11:34 PM
> To: Hadriel Kaplan
> Cc: IETF SIP List

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 29 Mar 2009 01:56:15 +0100

Interestingly I made a measurement which supports your argument.
In short, a vast majority of SIP traffic going through iptel.org
has IP address in it. Details of the measurement follow bellow
for those interested in details (including links to colorful
non-ASCII graphs ;-)). Key characteristics of the  iptel.org
SIP service is high variance in type of UAs using it.

As for the backwards-compatibility argument, I guess that it will
take same long time to get UAs do session-id, so IMO an improvement
is only possible under an assumption that network-asserted session-id
is easier to introduce than UA-asserted, right? That appears
meaningful to me.

-jiri (hoping for better life for unfortunate ones, who have chosen
to operate callid-mangling B2BUAs and RFC-2543 clients without upgrade
strategy  ;-))

Measurement Details
--------------------
a) types of UA
for a pie-chart see: http://www.iptel.org/~jiri/etc/ua-breakdown.png
(picture to big to be attached, sorry)
It is saying that there are 162 diffent types of User Agents for
1131 users. Apart from the most popular UA types seen in the graph,
the greatest variety occurs in the "other devices" chunk representing
150+ User Agent Types.
In summary I think the selection of UAs is quite representative.

b) callid stats
I pulled about 18 minutes of SIP traffic at about 0.5 Mbps (including
layer-2 headers; resulting in about 65e3 packets totaling to 35e6
bytes of SIP data, avg SIP packet size 540 bytes) and postprocessed
it as follows:

# IP addres in grep -v is an availabaility checker -- to be excluded
ngrep -d any -W byline  port 5060| grep -i Call-ID|grep -v 
"213.192.59.93"|sort -u >/tmp/callid2
# number of callids captured in the sample: 4345
tlb1:~# wc /tmp/callid2
   4345   8733 184947 /tmp/callid2
# number of @IP callids: 3695 (85%)
tlb1:~# egrep "@[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" 
/tmp/callid2|wc
3695    7433  152577
# number of callids w/o @: 470 (11%)
tlb1:~# egrep -v "@" /tmp/callid2|wc
     470     940   23053
# numver of callids with @ and some non-nummerical stuff after it 
(domain name typically)
tlb1:~# egrep  "@[^0-9]" /tmp/callid2|wc
     149     298    8220
# number of "natted callids"
tlb1:~# egrep  "@(10|192\.168|172\.(16|17|18|19|2[0-9]|30|31))\." 
/tmp/callid2|wc
    1092    2184   47063

c) measurement mistakes: a and b have been measured independently, it
is possible but unlikely that the statements in b related to a different
set of UAs featuring  a different variance. This likelihood of such
circumstances to occur doesn't seem very high to me. b) has been measured
on an off-the shelf PC attached to the same Ethernet swtich at iptel.org's
load-balancer --it is possible that such a PC could have missed some
IP packets. If so, I assume it has done so on a fair basis which does not
impact the CallId assertion.

[email-masked] wrote:
> Jiri,  
> I agree with you on the im portance of the problem, but I don't agree

---

From: Theo Zourzouvillys <[email-masked]>
Date: Sun, 29 Mar 2009 12:59:03 +0100

On Sun, Mar 29, 2009 at 1:56 AM, Jiri Kuthan <[email-masked]> wrote:

> has IP address in it.

Yup, i have come to the same conclusion with our customers, too.

 ~ Theo

---

From: Victor Pascual Ávila <[email-masked]>
Date: Mon, 30 Mar 2009 19:18:14 +0200

On Sun, Mar 29, 2009 at 2:56 AM, Jiri Kuthan <[email-masked]> wrote:
(snip)
> is easier to introduce than UA-asserted, right? That appears

I'm still worried about out-of-dialog messages referencing to Call-ID
values. It sounds like "you break it, you fix it".
-- 
Victor Pascual Ávila