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

[Olle E. Johansson]

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'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