Subject: RE: [Sip] REFER security options - removing Referred-By

From: "Sriram Parameswar"<[email-masked]>
Date: Mon, 8 Apr 2002 14:06:17 -0500

Hi:

The thread "Reason format: removing reason codes" triggered this thought.
Why not use a Reason header to indicate that an INVITE is due to a REFER? We
could come up with a Reason code for this. That way the argument that there
is no way to tell a regular INVITE from one that has been caused by a REFER
goes away!

Thx,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: [email-masked]

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Monday, April 08, 2002 9:23 AM
To: Nigel Dewdney
Cc: [email-masked]
Subject: Re: [Sip] REFER security options - removing Referred-By

On Mon, 2002-04-08 at 08:30, Nigel Dewdney wrote:
> Robert,
> Inline:
> 
> Robert Sparks wrote:
> 
> > On Fri, 2002-04-05 at 09:07, Nigel Dewdney wrote:
> > > Pardon me if I'm being obtuse, but how do I tell whether an INVITE is
as
> > > a result
> > > of a REFER or not if Referred-By is dropped?
> >
> > That's exactly the point - you wouldn't.
> >
> 
> I would argue this is a bad thing. A referral and an unsolicited invited
are
> conceptually two different things. The endpoint should be aware of the
> type of process it is involved in. Whether it chooses to do anything
> different as a result is another question.

So, are you saying
"It will not be useful to have a version of REFER that doesn't
 make the triggered request distinct from an ordinary request."?

That's different from
"It will be useful to have a version of REFER that does make
the triggered request distinct from an ordinary request."

I agree with the second statement. I'm not convinced yet on the first.

> [snip]
> 
> > > the REFER mechanism
> > > has been reduced into one of "hey don't call me call them!", i.e. the
> > > call from A to C is
> > > disassociated from the dialog between A and B.
> >
> > No - that's a separate problem. The kind of association you are
> > looking for here is what's being addressed through the Replaces header.
> >
> 
> Sorry, I meant association at a functional or application level. It comes
down
> to
> a question of granularity. Do you consider the referral process as one
that
> just
> tells the referree where to go, or one that includes the point of
referral?
> [snip]
> 
> > > The obvious example is where C wants to only
> > > accept calls
> > > which have been vetted by B. Irrespective of  security requirements,
> > > this requires
> > > that the primitive have a reference to B in A's request to C. How
about
> > You got your alphabet mixed up there.
> 
> Er, no. This is just another reference to Referred-By (no pun intended).
> A->B
> A<-B "please A, REFER to C"
> A->C
> C - "hey did A go through B before contacting me?"
> [snip]

Ah - I was using the model in the refer-sec-options draft that has
a REFER going from A to B. 
> 
> >
> > There are _clearly_ good applications waiting for the Referred-By
> > functionality. I am _NOT_ advocating we abandon providing it. What
> > I'm asking is whether or not the base level transfer application
> > really needs it. There are already fielded implementations that don't
> > use it providing some evidence that you have a useful service without
> > it.
> >
> 
> I didn't think for a moment that you were! :~) You could certainly achieve
> some base functionality without Referred-By, but then you could apply
> the same argument to other SIP methods. You could strip out some of the
> headers in INVITE and still get some base functionality, but I don't think
> anyone is arguing for that. You could remove the From header for example,
> as has already been alluded to on this thread. Its another point of
> granularity -
> you support a lot more with it than without. You can ignore the header if
> your application doesn't require it (treat it like the From: header).

Well, the same argument _did_ get applied to other SIP methods as they
were being defined. What we're left with is what we could agree on being
the minimal set of required headers. Of course, the bar was in a little
different place before we had an agreed on Supported/Require mechanism.

Your last sentence is nearing the root of the problem though.
Are you claiming that its OK to provide Referred-By and not secure it?
(where secure it means A provides a proof "X" to C through some
mechanism. X is a proof of at least A's identity, the content of the
Refer-To header A sends to B. There may be more stuff in the proof to
help defend against replay).

Are you claiming that it is sufficient to say in the draft that
an implementation receiving any request (other than a REFER) with a
Referred-By header and no such proof SHOULD ignore the header entirely
while processing the request? (This is analogous to saying an 
implementation SHOULD NOT display the contents of the From header
while the phone is alerting unless the UA has some proof of the
contents of that From header).

> 
> regards,
> 
> Nigel Dewdney
> Laboratory Telecommunication Sciences
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Robert Sparks <[email-masked]>
Date: 08 Apr 2002 14:21:17 -0500

I think the people that want to know the INVITE was because of a REFER
are interested in more than just that one bit of information - they
are really wanting to know who sent the REFER and what that entity
actually referred to. I don't know if we could reasonably code that
into Reason:

RjS
On Mon, 2002-04-08 at 14:06, Sriram Parameswar wrote:
> Hi: 
> 
> The thread "Reason format: removing reason codes" triggered this
> thought. Why not use a Reason header to indicate that an INVITE is due
> to a REFER? We could come up with a Reason code for this. That way the
> argument that there is no way to tell a regular INVITE from one that has
> been caused by a REFER goes away!
> 
> Thx, 
> 
> Sriram 
> 
> From: Robert Sparks [ mailto:[email-masked]
> <mailto:[email-masked]> ] 
> > > > Pardon me if I'm being obtuse, but how do I tell whether an INVITE
> is as 
> > > > a result 
> > I would argue this is a bad thing. A referral and an unsolicited
> invited are 
> > Sorry, I meant association at a functional or application level. It
> comes down 
> > to 
> <https://www1.ietf.org/mailman/listinfo/sip>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 08 Apr 2002 14:34:19 -0500

> been caused by a REFER goes away!

I have been only peripherally following the "REFER security options -
removing Referred-By" thread, so aplogies if I have misunderstood the
thread discussion thus not quite answering your question.

The reason why the Reason header will not be able to do this is that
in the following scenario:

    A, B in a conversation
    A refers B to C
    B sends C an INVITE

The INVITE from B to C would be considered outside of a dialog as far
as C is concerned.

Best regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and eServices
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216