RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt

["Brian Rosen" <[e-mail]>]

Keith

I am a little worried about policing RPH.

If a proxy puts the RPH on, and it stays in one domain until it's given to
the PSAP domain (the ESRP in most cases), then it might work.

However, if the endpoint asserts it, then we really have a problem with
fraud, especially if you take it at face value and say that you have a
priority on resources in the network.  I'm not really thinking about the
monetary value, but the ability to gain priority just by claiming to be an
emergency call.

It did occur to me that the solution offered by Richard Barnes for
validation of a PSAP URI in the presence of location hiding would work here,
but I suspect that the damage would be done by the time it was discovered
(which is at the exit point from the origination domain).  The other ideas
we had wouldn't work at all.

Brian

> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:[e-mail]]
> Sent: Friday, September 21, 2007 10:22 AM
> To: James M. Polk; Henning Schulzrinne
> Cc: ECRIT
> Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt
> 
> I think this is a case of horses for courses. People have said we should
> not overload headers, and we seem to have two separate functions - the
> routing function and the processing treatment function where emergency
> calls need to be recognised for special handling.
> 
> Where emergency calls in the network require special processing
> treatment, then I also consider the RPH header is appropriate. Note that
> this is not a case of treating emergency calls first, more a matter of
> making sure that they are not precluded by other heavy traffic.
> 
> I (now) understand the need to retain the service URN once a candidate
> PSAP address has been identified. This is a routeing function.
> 
> I think we need two separate solutions covering each problem. Each
> solution is inappropriate to cover the other problem.
> 
> Regards
> 
> Keith
> 
> > -----Original Message-----
> > From: James M. Polk [mailto:[e-mail]]
> > Sent: Wednesday, September 05, 2007 7:29 AM
> > To: Henning Schulzrinne; DRAGE, Keith (Keith)
> > Cc: ECRIT
> > Subject: Re: [Ecrit] Re: [Sip]
> > draft-rosenberg-sip-ua-loose-route-01.txt
> >
> > I believe I agree that the RPH shouldn't be relied upon as
> > the (or the only) enduring indication a call is an emergency call.
> >
> > I think the sos RPH namespace should be used within emergency
> > networks for resource treatment.
> > draft-polk-ecrit-local-emergency-rph-namespace-01.txt talks
> > about this.
> >
> > I also think it should be up to the arrangements between the
> > emergency network to and a service provider, say one with an
> > IMS architecture, to establish trust to a particular server,
> > perhaps each E-CSCF within that provider's network, to
> > appropriate PSAPs.  In this scenario, which should be
> > possible, but not necessarily pushed at this time, the *-CSCF
> > can add the sos RPH to an emergency SIP request.  The SP
> > would be taking on the charge of making sure the RPH wouldn't
> > cause harm within their network to the emergency services network.
> >
> > At 02:08 PM 9/4/2007, Henning Schulzrinne wrote:
> > >As for Brian, my preferred solution is the loose-route proposal.
> > >
> > >If we want an explicit marking, I think an explicit header would be
> > >clearest, as in
> > >
> > >Service: urn:service:sos.fire
> > >
> > >(I don't want this to be conflated with the service
> > discussion in SIP;
> > >this has nothing to do with what's been discussed there. I
> > don't care
> > >about the header label.)
> > >
> > >Resource priority is, in my opinion, not appropriate for marking the
> > >service requested since such calls may not actually get resource
> > >priority and since it is unlikely that fire calls will get a
> > different
> > >priority from police calls. Conversely, the RPH header is dangerous
> > >outside carefully controlled environments, since it can be a
> > DOS tool.
> > >In particular, RPH requires strong client authentication, which is
> > >generally not available in emergency calls. Within the
> > >(trusted) ESN, this isn't a major problem, but letting end users or
> > >VSPs set that header field is asking for trouble unless
> > other entities
> > >can verify that the call is indeed an emergency call. If they can do
> > >that, then you don't need the header.
> > >
> > >Overloading headers just because they are available doesn't
> > strike me
> > >as architecturally appropriate.
> > >
> > >Henning
> > >
> > >On Sep 4, 2007, at 9:06 AM, DRAGE, Keith ((Keith)) wrote:
> > >
> > >>(Removing parties from the original list distribution)
> > >>
> > >>The situation in 3GPP is that we have so far failed to agree any
> > >>marking or other carriage of other information (with a significant
> > >>number of the objections coming from the organisation
> > Christer works
> > >>for), not that we have agreed we don't want one.
> > >>
> > >>I believe the appropriate way forward on marking for
> > special handling
> > >>is actually the Resource-Priority header solution identified by
> > >>
> > >>http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-
> > >>emergency-rph-namespace-01.txt
> > >>
> > >>In terms of special handling, this makes a lot of sense for
> > those SIP
> > >>entities that already have to implement RFC 4412 for other
> > regulatory
> > >>reasons.
> > >>
> > >>As already indicated, the 3GPP E-CSCF (the emergency routeing
> > >>proxy) changes the Request-URI to the PSAP URI, and the original
> > >>Reuqest-URI is lost. Once we have reached the E-CSCF, is
> > the original
> > >>Request-URI (the service URN) still important for any issue
> > apart from
> > >>special handling?
> > >>
> > >>Regards
> > >>
> > >>Keith
> >
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ecrit