Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Jul 2015 15:30:25 +0000

I've now read all the versions of meeting notes distributed.

None of these expand on Cullen's privacy concern, so perhaps he could elaborate.

I would state that:

1)	the trust statements in the document relate only to the additional header field. The privacy requirements on the remainder of the Geolocation header field are unchanged.

2)	for SIP deployments that use trust, neither the trust nor the entities involved in that trust are the same for every header field. So the trust for RFC 3325 is: a) on the sender to trust that the recipient to apply any "id" privacy indicated; b) on the recipient that they trust the sender to assert the identity. For this draft, the only trust required is that the receiver trusts the sender to assert that the new header field parameter was applied by a "originating telephony or electronic communications service provider".

3)	I do not believe there is any privacy issue about the recipient receiving information that any contained Geolocation header field came from a "originating telephony or electronic communications service provider" as opposed to anywhere else. If there is, then the trust requirements could be altered in the same manner as already used for a number of 3GPP specific header fields.

Keith

> -----Original Message-----
> From: DRAGE, Keith (Keith) 
> Sent: 22 July 2015 10:17
> To: [email-masked]
> Subject: draft-winterbottom-dispatch-locparam
> 
> Issues from the dispatch meeting discussion:
> 
> 1)	In regard to trust, what is needed is a mechanism to 
> meet the following from the EC mandate:
> 
> ". The enhancement, i.e. location data provision, is expected 
> to be determined by the originating telephony or electronic 
> communications service provider, capable of originating voice 
> calls through a number or numbers in national telephone 
> numbering plans, and be provided at call setup to the PSAP as 
> soon as the call reaches the authority handling the emergency calls."
> 
> The proposal in the document is that the recipient of a SIP 
> request will either know that the entity that sent or proxied 
> the SIP request is either an "originating telephony or 
> electronic communications service provider" or trusts that 
> entity to make a proper discrimination of that.
> 
> Relying on certificates or known domain names would require 
> PSAPs and networks routeing emergency calls to have a 
> maintained database of all known "originating telephony or 
> electronic communications service provider" worldwide.
> 
> 2)	The question was raised as to whether it should be 
> specific for emergency call. I see no reason why it should 
> be. It does not interfere with the location itself, or the 
> privacy of the location itself. Further, I have a concern of 
> any protocol mechanism that is emergency call specific, as it 
> never gets tested until one wants to make an emergency call.
> 
> 3)	I believe Cullen mentioned privacy, but I am not sure 
> in what context. The mechanism does not interfere with any of 
> the privacy requirements defined for the Geolocation header 
> field. Further if the trust in 1) above is not met, it is 
> only the parameter that is removed, not the Geolocation 
> header field itself.
> 
> Regards
> 
> Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jul 2015 11:44:32 -0400

> 2)	for SIP deployments that use trust, neither the trust nor the entities involved in that trust are the same for every header field. So the trust for RFC 3325 is: a) on the sender to trust that th…

There is also a need for some entity to police the incoming trust 
boundary, and remove assertions (locparam values in this case) inserted 
by untrusted elements.

	Thanks,
	Paul

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Jul 2015 15:46:26 +0000

To correct one error. In item 1) 1st sentence "additional header field" should be "additional header field parameter"

Keith

> From: dispatch [mailto:[email-masked]] On Behalf 
> Of DRAGE, Keith (Keith)
> Sent: 22 July 2015 16:30
> To: [email-masked]; Cullen Jennings
> Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam
> 
> 1)	the trust statements in the document relate only to the 
> additional header field. The privacy requirements on the 
> remainder of the Geolocation header field are unchanged.
> 
> 2)	for SIP deployments that use trust, neither the trust 
> nor the entities involved in that trust are the same for 
> every header field. So the trust for RFC 3325 is: a) on the 
> sender to trust that the recipient to apply any "id" privacy 
> indicated; b) on the recipient that they trust the sender to 
> assert the identity. For this draft, the only trust required 
> is that the receiver trusts the sender to assert that the new 
> header field parameter was applied by a "originating 
> telephony or electronic communications service provider".
> 
> 3)	I do not believe there is any privacy issue about the 
> recipient receiving information that any contained 
> Geolocation header field came from a "originating telephony 
> or electronic communications service provider" as opposed to 
> anywhere else. If there is, then the trust requirements could 
> be altered in the same manner as already used for a number of 
> 3GPP specific header fields.
> 
> Keith
> 
> > ". The enhancement, i.e. location data provision, is expected to be 
> > determined by the originating telephony or electronic 
> communications 
> > service provider, capable of originating voice calls 
> through a number 
> > or numbers in national telephone numbering plans, and be 
> provided at 
> > call setup to the PSAP as soon as the call reaches the authority 
> > handling the emergency calls."
> > 
> > The proposal in the document is that the recipient of a SIP request 
> > will either know that the entity that sent or proxied the 
> SIP request 
> > is either an "originating telephony or electronic communications 
> > service provider" or trusts that entity to make a proper 
> > discrimination of that.
> > 
> PSAPs and 
> > networks routeing emergency calls to have a maintained 
> database of all 
> > known "originating telephony or electronic communications service 
> > provider" worldwide.
> > 
> be. It does 
> > not interfere with the location itself, or the privacy of 
> the location 
> > itself. Further, I have a concern of any protocol mechanism that is 
> > emergency call specific, as it never gets tested until one wants to 
> > make an emergency call.
> > 
> > in what context. The mechanism does not interfere with any of the 
> > privacy requirements defined for the Geolocation header 
> field. Further 
> > if the trust in 1) above is not met, it is only the 
> parameter that is 
> > removed, not the Geolocation header field itself.
> > 
> > Regards
> > 
> > Keith

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Jul 2015 15:55:47 +0000

Yes.

That is in the draft, and I thought it was reasonably implicit in the summary. I'm not trying to rewrite the procedures here.

But in general, if the received header field parameter is not trusted, then it is removed by the receiver.

Keith 

> Of Paul Kyzivat
> Sent: 22 July 2015 16:45
> There is also a need for some entity to police the incoming 
> trust boundary, and remove assertions (locparam values in 
> this case) inserted by untrusted elements.
> 
> 	Thanks,
> 	Paul
> 
> >> Relying on certificates or known domain names would 
> require PSAPs and 
> >> networks routeing emergency calls to have a maintained database of 
> >> all known "originating telephony or electronic 
> communications service 
> >> provider" worldwide.
> >>
> >> specific for emergency call. I see no reason why it should be. It 
> >> does not interfere with the location itself, or the privacy of the 
> >> location itself. Further, I have a concern of any protocol 
> mechanism 
> >> that is emergency call specific, as it never gets tested until one 
> >> wants to make an emergency call.
> >>
> >> privacy requirements defined for the Geolocation header field. 
> >> Further if the trust in 1) above is not met, it is only 
> the parameter 
> >> that is removed, not the Geolocation header field itself.
> >>
> >> Regards
> >>
> >> Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jul 2015 12:24:43 -0400

> But in general, if the received header field parameter is not trusted, then it is removed by the receiver.

The point of Spec(T) was to enumerate the things that must be specified. 
ISTM it would make sense for this draft to reference 3325 for a 
definition of Trust, rather than leaving it vague and loosely specified. 
Since the chief customer for this is IMS, and it already depends on 
3325, it doesn't seem like a big burden.

In particular, it makes clear that some elements sit on a trust boundary 
and are responsible for policing, while other elements may not be on a 
boundary and have no responsibility for policing.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Jul 2015 16:36:25 +0000

To be clear, the chief customer of this at the moment is VoIP providers and emergency service providers in Europe that do not do IMS. IMS is a parallel architecture that currently does not specify this for location, although possibly it could in the future.

I do agree that the document needs to be clear about what is meant by trust.

But the point of my posting was to try and elaborate and close the issue Cullen was raising about privacy.

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 22 July 2015 17:25
> To: DRAGE, Keith (Keith); [email-masked]
> > That is in the draft, and I thought it was reasonably 
> implicit in the summary. I'm not trying to rewrite the 
> procedures here.
> >
> > But in general, if the received header field parameter is 
> not trusted, then it is removed by the receiver.
> 
> ISTM it would make sense for this draft to reference 3325 for 
> a definition of Trust, rather than leaving it vague and 
> loosely specified. 
> Since the chief customer for this is IMS, and it already 
> depends on 3325, it doesn't seem like a big burden.
> 
> In particular, it makes clear that some elements sit on a 
> trust boundary and are responsible for policing, while other 
> elements may not be on a boundary and have no responsibility 
> for policing.
> 
> 	Thanks,
> 	Paul
> 
> > Keith
> >
> >> From: dispatch [mailto:[email-masked]] On 
> Behalf Of Paul 
> >> Kyzivat
> >> Sent: 22 July 2015 16:45
> >> To: [email-masked]
> remainder of 
> >> the Geolocation header field are unchanged.
> >>>
> every header 
> >> field. So the trust for RFC 3325 is: a) on the sender to 
> trust that 
> >> the recipient to apply any "id" privacy indicated; b) on the 
> >> recipient that they trust the sender to assert the 
> identity. For this 
> >> draft, the only trust required is that the receiver trusts 
> the sender 
> >> to assert that the new header field parameter was applied by a 
> >> "originating telephony or electronic communications service 
> >> provider".
> >>
> >> boundary, and remove assertions (locparam values in this case) 
> >> inserted by untrusted elements.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> Geolocation header 
> >> field came from a "originating telephony or electronic 
> communications 
> >> service provider" as opposed to anywhere else. If there 
> is, then the 
> >> trust requirements could be altered in the same manner as already 
> >> used for a number of 3GPP specific header fields.
> >>>
> >>> Keith
> >>>
> database of

---

From: Michael Hammer <[email-masked]>
Date: Thu, 23 Jul 2015 14:26:34 +0000

Does that include any parameter that they just don't understand?

That could break things.  And not the general SIP policy?

________________________________
Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of DRAGE, Keith
(Keith)
Sent: Wednesday, July 22, 2015 11:56 AM
To: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam

Yes.

That is in the draft, and I thought it was reasonably implicit in the
summary. I'm not trying to rewrite the procedures here.

But in general, if the received header field parameter is not trusted, then
it is removed by the receiver.

Keith 

> From: dispatch [mailto:[email-masked]] On Behalf Of Paul 
> Kyzivat
> Sent: 22 July 2015 16:45
> To: [email-masked]
> additional header field. The privacy requirements on the remainder of 
> nor the entities involved in that trust are the same for every header 
> field. So the trust for RFC 3325 is: a) on the sender to trust that 
> the recipient to apply any "id" privacy indicated; b) on the recipient 
> that they trust the sender to assert the identity. For this draft, the 
> only trust required is that the receiver trusts the sender to assert 
> that the new header field parameter was applied by a "originating 
> recipient receiving information that any contained Geolocation header 
> field came from a "originating telephony or electronic communications 
> service provider" as opposed to anywhere else. If there is, then the 
> trust requirements could be altered in the same manner as already used 
> for a number of 3GPP specific header fields.
> >
> > Keith
> >