[asterisk-dev] AstriDevCon Follow Up - Asterisk and Kamailio - smoother integration

[Matthew Jordan]

On Tue, Mar 10, 2015 at 10:43 AM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
> Good to see the discussion had more people and wider approach on different
> levels, covering pure agnostic signaling up to specific application
> constraints.
>
> While being somehow silent, I worked to make a concrete step forward,
> developing a new module for kamailio named auth_xkeys -- for those
> interested, some details here:
>
>   * http://kamailio.org/docs/modules/devel/modules/auth_xkeys.html
>
> Specifically, the issue I wanted to solve with this one is the elasticity of
> authentication/trust relations between the nodes of a VoIP platform.
>
> So far most of authorization between Kamailio and Asterisk relies on IP
> addresses, but those need to be provisioned one by one in both sides. The
> new module is practically adding a custom header with a hash over parts of
> the message or other environment attributes (eg., IP address) and a shared
> secret. The www-digest with username and password has the overhead of an
> extra round of signaling messages, but also the constraint on CSeq increment
> after the challenge. Also, the MD5 is rather week hashing these days.
>
> Imagine I have a cloud of 200 asterisk/kamailio application servers and I
> want to add another Kamailio edge proxy/load balancer in Singapore to
> collect the traffic from the area based on DNS. Will require an update to
> 200 nodes for adding a new trusted IP. With a shared secret to build the
> auth key, that is transparent. Think about that you need to orchestrate the
> number of application servers and edge proxy dynamically to be able to cope
> with special situations (DDoS attacks, unexpected emergencies for lot of
> people (earthquake, etc...) or days of the year with lot of traffic
> (christmas, new year)).
>
> What I implemented with auth_xkeys is not something new, it is used a lot by
> the API web services (e.g., github) and I think it is good for SIP networks
> as well. It is more about secret keys management.
>
> What Asterisk devs think about it? Does it sound useful to get a similar
> mechanism in Asterisk? I can provide more tech details if needed, just ask.

I think it is a great idea. Adding support for the authentication
portion of it should be relatively straight forward, as the PJSIP
stack supports a 'pluggable' mechanism for performing authentication.
Currently, that mechanism is limited to a single module, but making it
support multiple authentication mechanisms wouldn't be difficult.

The configuration for it would potentially be the 'trickier' part, as
res_pjsip/config_auth.c sort of expects to provide the configuration
for all authentication modules. That could probably be changed, but it
may not really be worth breaking it up and/or having each potential
authenticator module provide its own configuration.

Either way, for said configuration, I'd envision it being something
along the lines of:

[my-endpoint]
type=auth
auth_type=xkeys
header=X-My-Key
hash_algorithm=sha256
password=secret
hash_header=CSeq,Call-ID

[my-endpoint]
type=endpoint
auth=my-endpoint

...

We would then have a new authenticator module plug itself into the
stack and - when a message needs to be authenticated - use the
mechanism outlined in your proposal as opposed to the typical digest
authentication.

A more difficult part of the proposal is the following:

{quote}
Another goal is to provide more elasticity for scalability needs of
the core SIP network nodes. Most of the nodes in the core network or
the interconnecting peers trust each other based on IP address. But
adding a new node requires updates to the exiting ones to trust the IP
address of the new node. On large deployments, that can become rather
complex. For example, as a replacement for IP trust relationships, the
sender can hash the local IP with the secret shared key, add it in the
header and the receiver will check if the source ip hased with the key
results in the same value.
{quote}

Being a B2BUA, Asterisk needs some knowledge about who sent it a
request. As a result, in the PJSIP stack, everything ends up getting
mapped to a PJSIP endpoint. In fact, we won't even bother performing
authentication if the received request isn't from an endpoint that we
"know" about - we'll simply respond with a 401. Even in the case where
Asterisk has been told to handle SIP requests from anonymous endpoints
(that is, requests from anyone), there's even a special 'anonymous'
endpoint identifier that can be loaded which will implicitly match
itself to any request that a more concrete endpoint identifier passed
on. In that Scenario, we still map the inbound request to a PJSIP
endpoint, i.e., the 'anonymous endpoint'.

I don't like the idea of recommending the usage of the anonymous
endpoint identifier when the goal of this is to determine whether or
not a received request from a previously unknown node is acceptable.

The crux of this is that if we receive a SIP request from a new node
in the network, then today, we won't have any way to identify the new
node, even with the proposed scheme above. I'm kind of curious how we
would manage the endpoint identification with the scheme proposed
above. We may trust that the request we received is from a valid
participant in the network, but how do we know what kind of
participant they are?

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org