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

[Olle E. Johansson]

2 sep 2009 kl. 10.11 skrev 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.
>

While showering, I tried to consider what would happen if I fake an  
INVITE over TCP and add a Contact: with a known peer's IP and port.  
Since Asterisk doesn't set up a new TCP connection (last time I  
checked) to the Contact: uri, but re-use the existing connection all  
the time (regardless of NAT) the fake Contact won't affect the call.  
If there's no authentication, I'll be able to use that peer's context  
and get access to the services. Proper permit/deny settings will  
prevent this though, but I'm not sure that everyone that has peer  
definitions in sip.conf has ACL settings.

oops.

/O