[sr-dev] git:andrei/cancel_reason: tm: Reason header copy for received CANCELs

[Iñaki Baz Castillo]

El Miércoles, 3 de Marzo de 2010, Andrei Pelinescu-Onciul escribió:
> On Mar 02, 2010 at 20:10, I?aki Baz Castillo <ibc at aliax.net> wrote:
> > El Martes, 2 de Marzo de 2010, Andrei Pelinescu-Onciul escribi?:
> > > tm: Reason header copy for received CANCELs
> > >
> > > When canceling branches due to a received CANCEL, use the Reason
> > > headers in the received CANCEL (all the Reason headers from the
> > > received CANCEL will be copied in the generated CANCELs, see
> > > RFC3326 for more details).
> >
> > Hi Andrei, great addition. However there could be a minor security issue:
> >
> > Perhaps it wouldn't be safe to propagate any Reason header coming in a
> > CANCEL from any sender (imagine you receive a malicius call at 5 o'clock
> > in the night and the hacker added "Reason" header to the CANCEL so you
> > don't find that call in the missed calls list of the phone).
> >
> > - This local policy could be implemented as follows:
> >
> > a) Enabling a flag in t_relay() that only makes sense for CANCEL rather
> > than INVITE, so:
> 
> I've added support for it. It can be turned on/off per transaction by
> using t_set_no_e2e_cancel_reason(0|1). The default state is controlled
> by e2e_cancel_reason modparam or runtime config variable
> (e.g. sercmd cfg.set_now_int tm e2e_cancel_reason 0 # disable).

Great :)


> >   if (is_method("CANCEL")) {
> >     if ($si == MY_APPLICATION_SERVER_IP)
> >       # Allow propagating "Reason" header.
> >       t_relay(0x12);
> 
>         ^^^^^^^^^^^^^
>         this would look like this:
>         t_set_no_e2e_cancel_reason(1);
>         t_relay();
> 
> >     else
> >       t_relay();
> >   }
> 
> Note that you could use t_set_no_e2e_cancel_reason() at any time, before
> or after creating the transaction.

So this can be set during INVITE transaction, right? this is really better 
than what I suggested.


> local_cancel_reason can be turned on/off independently, but only
> globally (I couldn't find any reason for wanting to do it per
> transaction).

Neither me as such "Reason" header is trusted (it has been created locally by 
SR, so it's safe to allow it always).


Thanks a lot.


-- 
Iñaki Baz Castillo <ibc at aliax.net>