[SR-Users] uac_replace_from and header adulterations

[Daniel-Constantin Mierla]

Hello,


On 13.10.17 21:53, Alex Balashov wrote:
> Hello,
>
> I've got a bizarre problem caused by bad UA behaviour:
>
>    UA A ---> Kamailio (P) ---> UA B
>
> 1. UA A sends initial INVITE through P to B;
>
> 2. Kamailio (P) makes some modifications to the From header using
> uac_replace_from() and passes along to B.
>
> 3. B sends an in-dialog request (e.g. BYE or reinvite) to A through P;
> in doing so, it modifies the To (formerly From) value slightly,
> replacing the hostname portion in the To URI with a different value to
> the one that was received in the From header.
>
> 4. Kamailio relays this in-dialog request to A, but with an
> adulterated/clipped/truncated/grammatically invalid To header now.
>
> 5. A responds with 400 Bad Request due to invalid To header.
>
> I would not dispute that UA B should not be modifying the remote URI in
> this manner. But since it does, it gives rise to two questions:
>
> 1. Why does Kamailio not simply discard the modified To header and
> restore the original value stored in the Record-Route rider parameter?
>
> Is it because the Record-Route parameter does not contain the original
> header value, but rather some data complementary to the current header
> value? 
>
> Or is it because the UAC code takes a checksum of the original remote
> URI header value and stores it, and just checks it when restoring on
> principle? If so, what's the motive for that?
>
> 2. Wouldn't it be better behaviour to simply reject a request so
> malformed, rather than passing it on with a corrupt restored value? If
> Kamailio can detect that the header has been tampered with, why pass it
> on?
>
what version of kamailio are you using in this case? Later versions of
kamailio should not set a broken header in that case (no header with
invalid chars). So the initial header is no longer stored, and you don't
get the bad request anymore.

Anyhow, the implementation is not storing the initial value, but, iirc,
some XOR'ed value based on initial value, new value and a key. Maybe
this should be changed.

On the other hand, there is already an alternative mode to store the
initial values using dialog, see the parameters of uac module. This
should work at this moment for your situation.

Also, in many cases lately as devices are rfc3261 compliant I just
replace the headers for the initial request and for the requests within
dialog I do anonymous values, they should not be used for Caller ID and
dialog matching is done on tags (keeping the from/to uri unchanged is a
requirement to cope with rfc2543 devices).

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
Kamailio World Conference - www.kamailioworld.com