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

[Nick Lewis]

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

I think that we need to be clear what the objective of peer matching is.


(i) It must not be a security mechanism - only digest authentication can
do this. Most systems do not currently support authentication for 
sending INVITEs to uac registrees. I do not think that asterisk does 
either. If some security is required then perhaps this is a place to 
start. Let us have one asterisk registered to another using the existing

password support but add another password for INVITEs coming from the 
server asterisk system to the client asterisk system.

(ii) It must be a distinguishing mechanism - each peer represents an 
individual interface on the pbx. It cannot be acceptable to have 
incoming calls to different properly registered peers being arbitarily 
ascribed to the same interface solely because of the same source ip.
Therefore the request line uri must be used as intended in rfc3261. The 
register contact used in the request line uri could be generated or 
configured. Its only requirement is that it be unique on the asterisk 
system so that the correct interface is selected. It must not be used 
for security.

(iii) It *could* be a familiarity mechanism - as long as this is not 
confused with a security mechanism or distinguishing mechanism. If the
source ip address and/or port of an INVITE matches that of a device
with which asterisk has had or intends to have peer communications then 
it may be acceptable to flag this as a familiarily match. The ip
addresses that should be included in a familiarity match are the host,
outbound proxy, registrar, srv resolved domain etc.

In the current implementation asterisk uses a subset of the matching in 
(iii) to act as both distinguishing mechanism and security mechanism. In

my view this form of matching is suitable for neither.

Nick_Lewis

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre.
_____________________________________________________________________
Disclaimer of Liability
ATL Telecom Ltd shall not be held liable for any improper or incorrect use of the  information described and/or contained herein and assumes no responsibility for anyones use  of the information. In no event shall ATL Telecom Ltd be liable for any direct, indirect,  incidental, special, exemplary, or consequential damages (including, but not limited to,  procurement or substitute goods or services; loss of use, data, or profits; or business  interruption) however caused and on any theory of liability, whether in contract, strict  liability, or tort (including negligence or otherwise) arising in any way out of the use of  this system, even if advised of the possibility of such damage.

Registered Office: ATL Telecom Ltd, Fountain Lane, St. Mellons Cardiff, CF3 0FB
Registered in Wales Number 4335781

All goods and services supplied by ATL Telecom Ltd are supplied subject to ATL Telecom Ltd standard terms and conditions, available upon request.