[asterisk-dev] Peer matching in trunk - matching on contact?

[Klaus Darilion]

Olle E. Johansson schrieb:
> After thinking about this a bit more, I now consider it a bug.
> 
> The Contact: header includes the UA's view of how other devices should  
> reach it. It might be an RFC1918 address or a public address. In some  
> cases, it might be the same as the sender's address, but not all the  
> time.
> 
> The peer matching is based on IP and port of the sender, the device  
> that sent the SIP request to Asterisk. Between the UA and the Asterisk  
> server, you might have several proxys.
> 
> The sender's IP address and the address in the contact are two very  
> different things. We should not match peers on the contact, unless  
> it's a new feature. If it's a new feature, it requires a new  
> configuration option, not type=peer. And matching on Contact does not  
> solve the problem described in the code comment. This code breaks the  
> current behaviour of type=peer for TCP sessions and causes new issues.

I second that. A "peer" is known to match on IP:port. If matching is 
done on Contact-/Request-URI it should have a new type=... 
(type=registration?) definition - otherwise it will cause confusion.

regards
klaus

> 
> I'm sorry I missed the commit of this code, but it really needs to go  
> away and we need to fix the issue - the IP/port matching on TCP  
> sessions, with or without TLS.
> 
> /O
> 
> 1 sep 2009 kl. 13.25 skrev Olle E. Johansson:
> 
>> While maintaining a new branch, I found this addition to the code
>> which surprised me a bit.
>>
>> I think matching based on a header in the SIP message really needs a
>> configuration option to be set, since this is highly insecure.
>>
>> Not saying that matching on ip and port numbers is secure, but relying
>> on the contact header for matching seems even more open for problems.
>>
>> And if it's impossible to match on p->recv when there's a TCP session,
>> why do we do that on the line above? Shouldn't that be disabled?
>>
>> We do need to start the campaign for "No more ugly patching, find a
>> new way of matching devices in chan_sip" - let's call it "Codename
>> Chestnut".
>>
>> /Olle
>> --------------------------
>>
>>  /* If the peer is still not found, try the address and port from the
>>                  * contact header.  If the transport type is TCP or
>> TLS it is not possible
>>                  * to find the peer using p->recv. Because of the way
>> TCP works, the received
>>                  * packet's destination port will not match the one
>> the peer table is
>>                  * built with. */
>>                 if (!peer && (p->socket.type != SIP_TRANSPORT_UDP)) {
>>                         struct sockaddr_in tmpsin;
>>                         char contact[SIPBUFSIZE];
>>                         char *tmp;
>>                         memcpy(&tmpsin, &p->recv, sizeof(tmpsin));
>>                         ast_copy_string(contact, get_header(req,
>> "Contact"), sizeof(contact));
>>                         tmp = get_in_brackets(contact);
>>                         __set_address_from_contact(tmp, &tmpsin, 1);
>>                         peer = find_peer(NULL, &tmpsin, TRUE,
>> FINDPEERS, FALSE);
>>                 }
>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
>> Register Now: http://www.astricon.net
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> ---
> * Olle E Johansson - oej at edvina.net
> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
> 
> 
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
> Register Now: http://www.astricon.net
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev