[SR-Users] Kamailio, spiral with TM

[David]

"Just make sure if a user fakes the internal headers, that they are not 
able to exploit something in your setup"

Hey,

I am using a few custom headers. All the custom headers , except the NAT 
one, are authenticated using IP, if the IP doesn't match, the packet is 
rejected ( or dropped ). ( I check the IPs using "ds_is_from_list()" )

The NAT related header is checked like this :

if ( nat_uac_test('19') && !is_present_hf('X-Cool-Header') )
{
   fix_nated_contact();
   # Set flags for NAT fixing such as RTP Proxy.
}

I am pretty sure this is safe.

Thanks,

David




On 2010-07-08 10:33, Klaus Darilion wrote:
>
>
> Am 08.07.2010 15:09, schrieb David:
>> Hey,
>>
>> OK, so after further research, I found that the trouble was not in fact
>> in the transaction, the trouble was with fix_nated_contact();
>>
>> So I setup a spiral SIP path. I have a public server that is used by a
>> bunch of different phones, and I have a alg server ( one public and one
>> private).
>>
>> The public server often handles NATed users and the private alg server
>> handles NAT for a particular user set ( the users on that particular
>> network) .
>>
>> The trouble is that the ALG does not rewrite the contact, rather it adds
>> a Route: header with Record-Route. The trouble was the public server was
>> calling fix_nated_contact on these users' requests, so when it came back
>> and the last route header was parsed, the packet could not be delivered
>> because the fix_nated_contact was changing the contact to the alg proxy
>> server.
>>
>> I added a custom header called "X-Ignore-NAT", and when I do the nat
>> tests ( nac_uac_test ), I also check that the X-Ignore-NAT header was
>> not present.
>>
>> So I misdiagnosed the problem that I described in my message. I did my
>> traces on the end point, so when I did not see the final packet arrive
>> to the device, I thought it was being reabsorbed.
>>
>> Is the custom header I used a good solution?
>
> If it works then it is a good solution. Custom headers are often used 
> provider internally to signal arbitrary data. Just make sure if a user 
> fakes the internal headers, that they are not able to exploit 
> something in your setup - e.g. you should screen incoming messages for 
> the existence of header names which will be used internally in your 
> network - and if you found such headers, just remove them.
>
> regards
> klaus
>
>>
>> David
>>
>> On 10-07-08 07:04 AM, Klaus Darilion wrote:
>>>
>>>
>>> Am 08.07.2010 00:53, schrieb David:
>>>> Hey,
>>>>
>>>> I do not do anything IP level forwarding. All my forwarding is done
>>>> using Kamailio. It looks like what I am doing is called hairpin 
>>>> routing.
>>>
>>> I think the correct term is "spiral" - at least the RFC uses this term.
>>>
>>> How do you forward the request - t_relay()? If yes, then tm module
>>> should treat the request as a new transaction.
>>>
>>> Post a trace (you can rewrite IP addresses):
>>> ngrep -t -q -W byline -d any -P "" port 5060 or 5061
>>>
>>> regards
>>> Klaus
>>>
>>>>
>>>> Thanks,
>>>>
>>>> David
>>>>
>>>> On 2010-07-07 18:48, Timo Reimann wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> David wrote:
>>>>>> I have setup two Kamailio servers, my INVITEs will go through
>>>>>> server A,
>>>>>> which forwards to server B which forwards it back to server A.
>>>>>>
>>>>>> This is intential, the trouble is when the packet comes back through
>>>>>> server B, nothing has changed so TM sees it as a retransmission.
>>>>>>
>>>>>> The difference between the first time through and the second time
>>>>>> is the
>>>>>> port 5061 instead of 5060.
>>>>> If you forward the INVITE from B to A SIP-wise (e.g., by calling
>>>>> forward()) a new Via header should be added which prevents the 
>>>>> spiraled
>>>>> INVITE message from being considered a retransmission on A.
>>>>>
>>>>> Do you perform forwarding on a lower level, like IP?
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> --Timo
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
>>>> list
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users