Fwd: [SR-Users] kamailio routes packets with invalid From/To headers with uac.restore_mode=auto when incoming packet does not use exact same replaced From/To header
31 Jul
2014
31 Jul
'14
5:46 p.m.
-------- Mensaje original --------
Return-Path: <sr-users-bounces(a)lists.sip-router.org>
Delivered-To: <a_villacis(a)palosanto.com>
Received: from palosanto.com by mail.palosanto.com (Dovecot) with LMTP id
1RBBAn9f2VPPOgAA3RMWGw for <a_villacis(a)palosanto.com>om>; Wed, 30 Jul 2014 16:14:09
-0500
Received: from localhost (mail.palosanto.com [127.0.0.1]) by palosanto.com (Postfix) with
ESMTP id BD82513C027E for <a_villacis(a)palosanto.com>om>; Wed, 30 Jul 2014 16:14:09
-0500 (ECT)
X-Virus-Scanned: Debian amavisd-new at mail.palosanto.com
X-Spam-Flag: NO
X-Spam-Score: -2.231
X-Spam-Level:
X-Spam-Status: No, score=-2.231 tagged_above=-1000 required=6.31 tests=[AWL=-0.333,
BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, WEIRD_PORT=0.001] autolearn=unavailable
Received: from palosanto.com ([127.0.0.1]) by localhost (mail.palosanto.com [127.0.0.1])
(amavisd-new, port 10024) with ESMTP id LEfbzVEOoMof for <a_villacis(a)palosanto.com>om>;
Wed, 30 Jul 2014 16:14:04 -0500 (ECT)
Received: from www.kamailio.org (main.kamailio.org [193.22.119.66]) by palosanto.com
(Postfix) with ESMTPS id 4412B13C0280 for <a_villacis(a)palosanto.com>om>; Wed, 30 Jul
2014 16:13:56 -0500 (ECT)
Received: from localhost ([127.0.0.1] helo=main.kamailio.org ident=list) by
www.kamailio.org with esmtp (Exim 4.72) (envelope-from
<sr-users-bounces(a)lists.sip-router.org>) id 1XCbCY-0000J5-PL; Wed, 30 Jul 2014
23:14:22 +0200
Received: from lab2.palosanto.com ([201.234.196.173] helo=palosanto.com) by
www.kamailio.org with esmtp (Exim 4.72) (envelope-from <a_villacis(a)palosanto.com>)
id 1XCbCU-0000II-SD for sr-users(a)lists.sip-router.org; Wed, 30 Jul 2014 23:14:19 +0200
Received: from localhost (mail.palosanto.com [127.0.0.1]) by palosanto.com (Postfix) with
ESMTP id 5BC5613C0280 for <sr-users(a)lists.sip-router.org>rg>; Wed, 30 Jul 2014 16:13:43
-0500 (ECT)
X-Virus-Scanned: Debian amavisd-new at mail.palosanto.com
Received: from palosanto.com ([127.0.0.1]) by localhost (mail.palosanto.com [127.0.0.1])
(amavisd-new, port 10024) with ESMTP id jY5HkVjL2_h0 for
<sr-users(a)lists.sip-router.org>rg>; Wed, 30 Jul 2014 16:13:39 -0500 (ECT)
Received: from avillacis.palosanto.com (avillacis.palosanto.com [192.168.3.2]) by
palosanto.com (Postfix) with ESMTPSA id 3DFFD13C0279 for
<sr-users(a)lists.sip-router.org>rg>; Wed, 30 Jul 2014 16:13:39 -0500 (ECT)
Message-ID: <53D96020.2040508(a)palosanto.com>
Date: Wed, 30 Jul 2014 16:14:08 -0500
From: Alex Villacís Lasso <a_villacis(a)palosanto.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.sip-router.org>
Content-Type: multipart/mixed; boundary="------------030501020507030206060205"
Subject: [SR-Users] kamailio routes packets with invalid From/To headers with
uac.restore_mode=auto when incoming packet does not use exact same replaced From/To
header
X-BeenThere: sr-users(a)lists.sip-router.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.sip-router.org>
List-Id: "Kamailio \(SER\) - Users Mailing List"
<sr-users.lists.sip-router.org>
List-Unsubscribe: <http://lists.sip-router.org/cgi-bin/mailman/options/sr-users>,
<mailto:sr-users-request@lists.sip-router.org?subject=unsubscribe>
List-Archive: <http://lists.sip-router.org/pipermail/sr-users>
List-Post: <mailto:sr-users@lists.sip-router.org>
List-Help: <mailto:sr-users-request@lists.sip-router.org?subject=help>
List-Subscribe: <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>,
<mailto:sr-users-request@lists.sip-router.org?subject=subscribe>
Sender: sr-users-bounces(a)lists.sip-router.org
Errors-To: sr-users-bounces(a)lists.sip-router.org
I am currently handling a system that runs kamailio and asterisk in the same machine. The
kamailio instances are being used to emulate multiple SIP domains, by means of From/To
mangling of incoming packets, which are then routed to Asterisk. The attached
kamailio.cfg does this work.
There is an problem when handling SUBSCRIBE requests (as required for BLF and voicemail
indications). My configuration is written so that these SUBSCRIBE requests are not handled
by kamailio, but instead routed to asterisk. There is a failure to check
From/To headers to see whether NOTIFY packets generated as part of a subscription can be
restored using the information in Record-Route. The end result is that kamailio ends up
sending packets with garbled tags that are (rightly) rejected by the SIP endpoint.
The following is an example that demonstrates the issue (using Jitsi as endpoint):
After registration, Jitsi sends a SUBSCRIBE request:
SUBSCRIBE sip:avillacisIM@pbx.villacis.com SIP/2.0
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 2 SUBSCRIBE
From: "avillacisIM" <sip:avillacisIM@pbx.villacis.com>;tag=bf427f4a
To: "avillacisIM" <sip:avillacisIM@pbx.villacis.com>
Max-Forwards: 70
Contact: "avillacisIM"
<sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com>
User-Agent: Jitsi2.5.5255Linux
Event: message-summary
Accept: application/simple-message-summary
Expires: 3600
Via: SIP/2.0/UDP 192.168.3.2:5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f
Proxy-Authorization: Digest
username="avillacisIM",realm="pbx.villacis.com",nonce="U9lZJlPZV/r06Xep/ukc1UzAIO0V3TbS",uri="sip:avillacisIM@pbx.villacis.com",response="0e18f4913c2693f6154c91f158fb17fe"
Content-Length: 0
This packet is mangled by the configuration, and is sent to asterisk like this:
SUBSCRIBE sip:avillacisIM@pbx.villacis.com SIP/2.0
Record-Route:
<sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
Record-Route:
<sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 2 SUBSCRIBE
From: "avillacisIM"
<sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080>;tag=bf427f4a
To: "avillacisIM" <sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080>
Max-Forwards: 69
Contact: "avillacisIM"
<sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com>
User-Agent: Jitsi2.5.5255Linux
Event: message-summary
Accept: application/simple-message-summary
Expires: 3600
Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bKd941.2ab9cf36e41dc48855ae2cbe9a309d0a.0
Via: SIP/2.0/UDP
192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f
Content-Length: 0
The asterisk response for the SUBSCRIBE:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
127.0.0.1;branch=z9hG4bKd941.2ab9cf36e41dc48855ae2cbe9a309d0a.0;received=127.0.0.1;rport=5060
Via: SIP/2.0/UDP
192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f
Record-Route:
<sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
Record-Route:
<sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
From: "avillacisIM"
<sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080>;tag=bf427f4a
To: "avillacisIM"
<sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080>;tag=as5562e95e
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 2 SUBSCRIBE
Server: Asterisk PBX 11.11.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH,
MESSAGE
Supported: replaces, timer
Expires: 3600
Contact: <sip:avillacisIM@127.0.0.1:5080>;expires=3600
Content-Length: 0
This is in turn transformed back by kamailio, and sent to Jitsi like this:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f
Record-Route:
<sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
Record-Route:
<sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
From: "avillacisIM" <sip:avillacisIM@pbx.villacis.com>;tag=bf427f4a
To: "avillacisIM" <sip:avillacisIM@pbx.villacis.com>;tag=as5562e95e
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 2 SUBSCRIBE
Server: Asterisk PBX 11.11.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH,
MESSAGE
Supported: replaces, timer
Expires: 3600
Contact: <sip:avillacisIM@127.0.0.1:5080;alias=127.0.0.1~5080~1>;expires=3600
Content-Length: 0
Now asterisk wants to send a NOTIFY to the endpoint for the subscription. The NOTIFY looks
like this:
NOTIFY sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com
SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK658fa5fc;rport
Max-Forwards: 70
Route:
<sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>,<sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
From: "asterisk" <sip:asterisk@127.0.0.1:5080>;tag=as5562e95e
To:
<sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com>;tag=bf427f4a
Contact: <sip:asterisk@127.0.0.1:5080>
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX 11.11.0
Event: message-summary
Content-Type: application/simple-message-summary
Subscription-State: active
Content-Length: 89
Messages-Waiting: no
Message-Account: sip:*97@127.0.0.1:5080
Voice-Message: 0/0 (0/0)
Here is where the bug appears. The autoprocessing does not recognize that the From header
(From: "asterisk" <sip:asterisk@127.0.0.1:5080>;tag=as5562e95e) from the
above request has nothing to do with the saved information (vsf parameter). Instead, it
blindly mangles the From header, and does not even run a sanity check on the result before
routing it. The end result is shown below.
NOTIFY sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com
SIP/2.0
Record-Route: <sip:192.168.2.18;r2=on;lr=on;ftag=as5562e95e>
Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=as5562e95e>
Via: SIP/2.0/UDP 192.168.2.18;branch=z9hG4bK8333.8bfe7bc2bd554a8631f0d00d463b28ee.0
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK658fa5fc;rport=5080
Max-Forwards: 69
From: "asterisk"
<sip:asterisk@12(.0.0.1:5080.....@127.0.0.1:5080>;tag=as5562e95e
To:
<sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com>;tag=bf427f4a
Contact: <sip:asterisk@127.0.0.1:5080>
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX 11.11.0
Event: message-summary
Content-Type: application/simple-message-summary
Subscription-State: active
Content-Length: 89
Messages-Waiting: no
Message-Account: sip:*97@127.0.0.1:5080
Voice-Message: 0/0 (0/0)
From examination of the source code, the vsf and vst strings are base64 encodings of the
result of XORing the byte strings of the old and new tags. For this to work, the headers
of future packets should match. However, here kamailio does not realize that
the header does not match (by the ftag), and also does not check that the resulting
"restored" header is a valid header.
3556
days inactive
3556
days old
0 comments
1 participants
participants (1)
-
Alex Villacís Lasso