Subject: RE: [Sipping] refer and pstn

From: "Chris Boulton" <[email-masked]>
Date: Tue, 10 Jun 2003 16:28:10 +0100

Are these not security issues rather than base protocol problems.

Chris.

>-----Original Message-----
>From: Juha Heinanen [mailto:[email-masked]]
>Sent: 10 June 2003 16:20
>To: Christer Holmberg (LMF)
>Cc: Pascal Dore; [email-masked]
>Subject: RE: [Sipping] refer and pstn
>
>Christer Holmberg (LMF) writes:
>
> > You said that the problem was that the calling PSTN user doesn't
know
> > he is being transfered, and/or he doesn't know where he's being
> > transfered. Why is that problem different depending on if he is
being
> > transfered to another SIP user, or back to another PSTN user?
>
>the problem is quite different from the operator's point of view who is
>running the pstn gw.  if pstn gw gets a refer, it must somehow know
that
>the referred-by is not spoofed and that the referrer is allowed to
>initiate a call to the refer-to number.
>
>-- juha
>_______________________________________________
>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 10 Jun 2003 18:46:12 +0300

> Are these not security issues rather than base protocol problems.

i don't know what they are.  i was just asking, what were the makers of
pstn gws thinking when they included refer UAS capability in their
boxes.  how is an operator of such a gw suppose to solve these kind of
security issues.

-- juha

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 11 Jun 2003 15:39:32 -0700

Hi Juha,

There are really two issues here:

1) authorizing the REFER request
2) authorizing the triggered request

Authorizing a REFER request is fairly complicated, but for trunking 
gateways my guidelines to our developers where something along these 
lines:

- only accept REFER requests with a Refer-To scheme of SIP or tel 
(today I would include SIPS).
- only accept REFER requests in the context of an existing dialog (i 
think unsolicited REFER makes sense on a phone, but not on a gateway).
- authenticate that the originator of the REFER has the same 
credentials as the originator of the current dialog
- reject REFER requests with Refer-Tos for methods that you don't want 
to deal with (in my experience, INVITE is usually method anyone ever 
considers).
- ignore any non-relevant or unsupported Refer-To URI parameters (for 
example: ttl, transport)
- reject REFER requests with Refer-Tos that contain Vias, CSeq and 
certain other especially dangerous headers
- ignore another set of headers (like From) based on your policy
- include a Referred-By header
- if your policy is to send all new request through a proxy, send the 
REFER through the proxy

Then you authorize the triggered request.  However you have to consider 
the Referred-By header when you do so. This is especially important for 
say an INVITE with Replaces.

hope this helps.
thanks,
-rohan