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

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Wed, 1 Jul 2015 15:02:54 +0000

Hello James,
I read this draft and I have a couple of questions. The introduction says 

" Knowing the identity of the entity that added the location to the
   message allows the recipient to choose which location to consider
   first rather than relying solely on the order of the location values
   in the geolocation header field."

but the draft does not say how the recipient sorts the multiple location sources, and it doesn't say what is involved in "considering" the location information. 

Also the draft says:

" If a proxy receives a message
   from an untrusted source with the loc-src parameter set then it MUST
   remove the loc-src parameter before passing the message into a
   trusted network."

but does that help? i.e. does it not simply give less choice of location data to the recipient?

Regards,
Peter

> -----Original Message-----
> From: dispatch [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 30 June 2015 09:22
> To: James Winterbottom; [email-masked]
> Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam
> 
> Indeed, it is important for that this work be dispatched to the right place
> quickly and moves forward.
> Bruno
> 
> > -----Message d'origine-----
> > De : dispatch [mailto:[email-masked]] De la part de James
> > Winterbottom Envoyé : mardi 23 juin 2015 11:12 À : [email-masked]
> > Objet : [dispatch] draft-winterbottom-dispatch-locparam
> >
> > Hi All,
> >
> > I a notice about this draft a few weeks ago but haven’t seen and
> > follow up discussion.
> > This work is required in ETSI and I believe that as I understand from
> > some 3GPP folks they would like something similar to this also.
> >
> > https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-00
> >
> > I am just not sure where the right final home for it is.
> >
> > Cheers
> > James
> >
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jul 2015 10:51:19 -0400

James,

I was just looking at this draft. I don't understand what assumptions it 
is making regarding trust model. Is this intended specifically for 3gpp 
and its trust model? Section 4 says:

    If a proxy receives a message
    from an untrusted source with the loc-src parameter set then it MUST
    remove the loc-src parameter before passing the message into a
    trusted network.

Are we assuming a Spec(t) as defined in 3325?

And is that enough? The obvious issue is the potential for somebody to 
lie about the location source.

Also, the location is specified as a 'host'. I assume you mean that as 
defined in 3261, where it is defined as:

   host = hostname / IPv4address / IPv6reference

Is it really meaningful to use an IP?

Is the expectation that the recipient will simply use these with a 
whitelist or blacklist to determine preferences? Or else how will it be 
used?

	Thanks,
	Paul

On 6/23/15 5:11 AM, James Winterbottom wrote:
> Hi All,
>
> I a notice about this draft a few weeks ago but haven’t seen and follow up discussion.
> This work is required in ETSI and I believe that as I understand from some 3GPP folks they would like something similar to this also.
>

---

From: James Winterbottom <[email-masked]>
Date: Sun, 19 Jul 2015 11:49:52 +1000

Hi Paul,

Thanks for the comments.

I will get to the questions in a second. I just wanted to say that draft is kind of a stawman to indicate what we would like to do and what we had in mind, we are totally aware that it needs work, we just want to get it to the right group to get the work done.

I can answer the second set of questions quickly, I will need to look up the 3325 question.

Yes, somebody could lie, but if we were to assume some kind of trusted network then there are a multitude of other things that they could also lie about couldn’t they? 

Yes, I was referring to the host from 3261, and I agree that an IP address make little sense. Is there are a better way to specify what we are looking for?

I was thinking some kind of whitelist if terms of preference (how this gets created I see as being largely out of scope), I am not sure how much sense it makes to have a blacklist.

Cheers
James

> On 17 Jul 2015, at 12:51 am, Paul Kyzivat <[email-masked]> wrote:
> 
> James,
> 
> I was just looking at this draft. I don't understand what assumptions it is making regarding trust model. Is this intended specifically for 3gpp and its trust model? Section 4 says:
> 
> And is that enough? The obvious issue is the potential for somebody to lie about the location source.
> 
> Also, the location is specified as a 'host'. I assume you mean that as defined in 3261, where it is defined as:
> 
> Is the expectation that the recipient will simply use these with a whitelist or blacklist to determine preferences? Or else how will it be used?
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 19 Jul 2015 13:27:15 -0400

> I will get to the questions in a second. I just wanted to say that draft is kind of a stawman to indicate what we would like to do and what we had in mind, we are totally aware that it needs work,…

OK. It helps to know that.

> Yes, somebody could lie, but if we were to assume some kind of trusted network then there are a multitude of other things that they could also lie about couldn’t they?

Ideally there would be some way of signing the assertion, proving a 
right to use that name. Something like the stuff STIR is working on. But 
the STIR work won't cover this.

> Yes, I was referring to the host from 3261, and I agree that an IP address make little sense. Is there are a better way to specify what we are looking for?

If IP makes no sense, then you could simply require 'hostname'.

> I was thinking some kind of whitelist if terms of preference (how this gets created I see as being largely out of scope), I am not sure how much sense it makes to have a blacklist.

If that is the case, then I guess maybe a proxy inserting this may not 
want to insert the actual hostname of itself - it may want to insert a 
more general hostname for the domain it represents, since otherwise the 
whitelist might get long, or else might have to consist of patterns that 
match multiple hostnames.

	Thanks,
	Paul