[Serusers] uri==myself check and record_route()

[Jan Janak]

On 23-10 15:52, Maxim Sobolev wrote:
> >the above is true if dialog was established by local user.  in case the
> >dialog was established by foreign user and that foreign user sends
> >another, in-dialog request, then ftag will be equal to from tag.
> >
> >so i implemented a function that checks if ftag is equal to either from
> >or to tag, but didn't find it very useful after all.  such test namely
> >adds very little value to just checking if the request has to tag and
> >dropping the ones that don't and are not send by or to a local user.
> >
> > > It should be relatively easy to do it - upon startup SER can generate 
> > > some random string and then, when INVITE arrives, calculate one-way 
> > hash > using this value and some other parameters that must persist 
> > during the > dialog - e.g. Call-Id, From tag etc, then inserting it as a 
> > parameter > into the Record-Route field. Then we can always check is the 
> > mid-dialog > request should be serviced by us.
> >
> >yes, i too have suggested that we do something like that.  this kind of
> >scheme, however, has no protection over faking new requests or replays
> >if someone gets hold of one real request.
> 
> Yes, that's true, but it IMHO is impossible to do something about that. 
> In real world, however, it is very unlikely that a complete stranger 
> will be able to get somehow real request, to do this he should be able 
> to sniff communication channel between UA and proxy, in this case even 
> digest-based auth mechanism would be pretty weak.
> 
> >also, if one gets hold of
> >several real requests, then it would be possible to figure out what the
> >key was unless the key changes often enough.  so i have been wondering,
> >if such mechanism is worth implementing.
> 
> Not quite. If cryptographically-strong hashing function is used then it 
> would be almost impossible to figure out server's portion of the key, 
> even if attacker will be able to sniff channel during extended period of 
> time.

  To prevent replay attacks, the hash would have to be calculated also
  over To tag. The hash should contain To tag because it is generated by
  remote party and thus the possible "attacker" can't predict it's
  value.

  This also means we would have to update the Record-Route header
  field when processing 200 OK, which complicates things a bit.

  If we don't add To tag, then it would be really easy to use same hash
  for other requests as well provided that you use the same From tag.

  Another problem is that the hash can't have limited life-time because
  we don't know how long the session is going to take, so it will be
  possible to relay such messages forever.


  However, there is another problem that comes on my mind -- how such
  Record-Route parameters would affect interoperability. Given the large
  amount of negative feedback I got because of lr=on and using r2
  parameter mostly during Sip-its, I predict that including many (and
  quite long parameters) could cause interoperability problems.

  Due to presence if strict routers in the wild, we can't make them
  header field parameter (i.e. parameters behind >), becuase strict
  routers will put the Route header field into Request-URI stripping of
  all header field parameters.

  If we make them URI-parameters (i.e. before closing >), can we make
  sure that other implementations will be able to handle such
  Request-URI ? (Maybe I am too paranoid, but my experience is not very
  good).

  I agree with Maxim that figuring out the secret key would be pretty
  hard.

    Jan.