Subject: [Geopriv] Where we are / are we with L7-LCP

From: Andrew Newton <[email-masked]>
Date: Fri, 9 Mar 2007 14:44:54 -0500

In reviewing the comments on the L7-LCP problem statement and  
requirements draft,  I see three areas of conversation:

1) The name: location configuration protocol vs. location acquisition  
protocol.
2) The On-behalf-of feature.
3) Location signing.

With respect with #1, I have to say that discussion over the name of  
the effort is a distraction.  I would ask that participants refrain  
from this discussion.  I understand that one of the protocol  
proposals goes by the name LCP, but that is a consequence of the  
authors of that proposal helping the working group come to the  
conclusion that LCP is a separate issue than L-by-R.

For #2, some of the participants have come to the conclusion that OBO  
is also a separable issue, in that it is an LS-to-LS (LIS-to-LIS)  
issue and not an LCP issue, and that OBO should influence the  
requirements for L-by-R.  I realize that not everybody agrees with  
this, but for those who wish to have OBO constrained to the LCP  
problem it should be noted that there is no consensus for this  
position, and that OBO with regard to L-by-R and LS-to-LS would  
likely find consensus with their support.

Finally, there is #3... by far the thorniest issue with many  
differing views.  Here is my attempt to enumerate the positions  
(putting aside any IPR conversation):

   a) Those that don't support it.  There are many reasons, from  
complexity to disbelief about the use case to issues about  
administrative overhead.

   b) Those that support it only for L7-LCP.

   c) Those that support it for all types location configuration  
protocols.

Have I missed any angles?

-andy

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 9 Mar 2007 14:50:06 -0500

I think you forgot the big gorilla in the room on L7 LCP, which is the
choice of identifiers, and the issues associated with using IP addresses on
those identifiers in some circumstances.

I think your summary of the other three issues is good.

Brian

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, March 09, 2007 2:45 PM
> To: GEOPRIV WG
> Subject: [Geopriv] Where we are / are we with L7-LCP
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 9 Mar 2007 16:08:19 -0600

There is also the specification of a response time by the requesting
node.

I have posted on this item 3 times and have had no response, my
assumption therefore was that it was agreed to without opposition.

> Sent: Saturday, 10 March 2007 6:45 AM
> To: GEOPRIV WG

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Mar 2007 14:52:26 -0800

At 2:44 PM -0500 3/9/07, Andrew Newton wrote:
>Finally, there is #3... by far the thorniest issue with many differing views.  Here is my attempt to enumerate the positions (putting aside any IPR conversation):
>
>  a) Those that don't support it.  There are many reasons, from complexity to disbelief about the use case to issues about administrative overhead.
>
>  c) Those that support it for all types location configuration protocols.
>
>
>

Hmm, my complex, nuanced view of the engineering and social trade-offs
between making it possible for anyone to call a PSAP and making it
possible for the PSAP to determine if the call's originator is in their service
area seems to have collapsed into "don't support it".

</sarcasm, for the tone-impaired>

I don't think a) quite captures the issue I keep trying to raise. 

PSAPs want to limit the ability of attackers to use their resources.
One way they do that now is to limit who can talk to the PSAP to those
within their service area.

PSAPs can no longer use network topology to identify who is in their service
area.  They would like to use something else.  The location asserted by
the end user/network is used to identify  a PSAP which serves the area, but
the PSAPs are concerned that bad actors can assert false information to
discover/target PSAPs.  They would like the information used in those
assertions to be vouched for by someone they trust or with whom they
can build trust, and the information to be carried through to the PSAP.

Rather than have the clients doing the assertion being vouched for (now *there's
a problem*), they want one piece of information in the assertion to be
vouched for--the location.  If that is vouched for, the PSAP has higher confidence
that the call is from someone within their service area; that means that
they are no more likely to be an attacker than they would be with the
existing system (which allows for attackers to call from within the service
area).

The issue that I'm raising is that while the primary aim,"limit the ability of attackers
to use their resources", is laudable, useful, and strongly associated with apple
pie, good beer, and the comic-book hero of  your choice,  doing so by "limiting
the geographic range from which attacks may come" is only a strategy for
achieving it.  There are other potential strategies (including things like associative
IDS systems that do not work on single calls but work on patterns) that might
be more effective at thwarting the efforts of attackers to consume PSAP resources.
Recreating the old strategy in the new system might be possible (with a large,
likely unfunded mandate), but  it will take a lot of time and cruft to get it going.
Balancing the effort that goes into this strategy has to be weighed against whether
this strategy is effective in and of itself and whether it is the best use of the
community's resources.

Put another way, we need to focus on the real goal, rather than on whether this
strategy is the right way to achieve it.  Brian has been saying this in some ways
all along, but I think we've been hearing him say "how else can I limit callers
to a specific geographic area" rather than "how else can I preserve PSAPs
against attackers looking to consume their resources."

All that now said, I remind folks that it has all along been possible to sign
a PIDF-LO object using S/MIME; that's in the base standard.  Anyone looking
to create method for carrying location with a signature has only to pick
PIDF-LO as their format and that mechanism comes along for the ride.
That won't tell you who ought to sign it, when that signature out to be checked,
or what actions to take when it fails, but as I understand it folks want that
to be a matter of policy anyway.

					Ted

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 9 Mar 2007 18:37:19 -0600

Currently PSAPs can be called from anywhere in their service area and
they have processes and resources to deal with hoax calls. Not providing
them a mechanism to provide priority to calls arising from their service
area puts those processes and resources in peril by several orders of
magnitude. There is a precedent for the former and none for the latter.

It is quickly going to become common knowledge that a SIP call initiated
with a PIDF-LO value of your choosing can go to the emergency call
centre for that location. Unfortunately emergency calling is going to be
one of the first IP telephony location based routing services. We aren't
going to get the opportunity to find out how badly Pizza Hut gets
impacted first.

Your argument is just another rehash of the "if it's not perfect than
it's not worth having." This is making perfect the enemy of good.

Signing the whole PIDF-LO per the S/MIME mechanism has been suggested
before. There are a couple of problems.

1. The signature also needs to cover the time of applicability and the
unique LIS client identity. These aren't, currently, part of the
PIDF-LO.

2. There are parts of the PIDF-LO that should still be able to be
changed by the location object recipient and, potentially, some proxies.
If the signature applies to the whole object then this won't be
possible.

In addition to the source of the location, the signature covers the time
of applicability of the location information and the identity of the LIS
client. These provide additional criteria for an automatic policy filter
to use depending on PSAP congestion. Without a signature mechanism, you
are dooming the PSAP operators - the human beings - to having to apply
those policies manually; if you get to that point you've already lost.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Saturday, 10 March 2007 9:52 AM
To: Andrew Newton; GEOPRIV WG
Subject: Re: [Geopriv] Where we are / are we with L7-LCP

At 2:44 PM -0500 3/9/07, Andrew Newton wrote:
>Finally, there is #3... by far the thorniest issue with many differing
views.  Here is my attempt to enumerate the positions (putting aside any
protocols.

Hmm, my complex, nuanced view of the engineering and social trade-offs
between making it possible for anyone to call a PSAP and making it
possible for the PSAP to determine if the call's originator is in their
service
area seems to have collapsed into "don't support it".

PSAPs can no longer use network topology to identify who is in their
service
area.  They would like to use something else.  The location asserted by
the end user/network is used to identify  a PSAP which serves the area,
but
the PSAPs are concerned that bad actors can assert false information to
discover/target PSAPs.  They would like the information used in those
assertions to be vouched for by someone they trust or with whom they
can build trust, and the information to be carried through to the PSAP.

Rather than have the clients doing the assertion being vouched for (now
*there's
a problem*), they want one piece of information in the assertion to be
vouched for--the location.  If that is vouched for, the PSAP has higher
confidence
that the call is from someone within their service area; that means that
they are no more likely to be an attacker than they would be with the
existing system (which allows for attackers to call from within the
service
area).

The issue that I'm raising is that while the primary aim,"limit the
ability of attackers
to use their resources", is laudable, useful, and strongly associated
with apple
pie, good beer, and the comic-book hero of  your choice,  doing so by
"limiting
the geographic range from which attacks may come" is only a strategy for
achieving it.  There are other potential strategies (including things
like associative
IDS systems that do not work on single calls but work on patterns) that
might
be more effective at thwarting the efforts of attackers to consume PSAP
resources.
Recreating the old strategy in the new system might be possible (with a
large,
likely unfunded mandate), but  it will take a lot of time and cruft to
get it going.
Balancing the effort that goes into this strategy has to be weighed
against whether
this strategy is effective in and of itself and whether it is the best
use of the
community's resources.

Put another way, we need to focus on the real goal, rather than on
whether this
strategy is the right way to achieve it.  Brian has been saying this in
some ways
all along, but I think we've been hearing him say "how else can I limit
callers
to a specific geographic area" rather than "how else can I preserve
PSAPs
against attackers looking to consume their resources."

All that now said, I remind folks that it has all along been possible to
sign
a PIDF-LO object using S/MIME; that's in the base standard.  Anyone
looking
to create method for carrying location with a signature has only to pick
PIDF-LO as their format and that mechanism comes along for the ride.
That won't tell you who ought to sign it, when that signature out to be
checked,
or what actions to take when it fails, but as I understand it folks want
that
to be a matter of policy anyway.

					Ted

---

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Mar 2007 17:22:12 -0800

>magnitude. There is a precedent for the former and none for the latter.

Agreed, though I prefer the formulation I gave below, as it retains the
distinction between network topology and service area that gives
rise to this change.

>it's not worth having." This is making perfect the enemy of good.

No, it isn't, and if you read it that way I obviously need to put more
work into it.  It's saying that the *real* goal is "help PSAPs limit
attacks", not "help PSAPs limit callers to those within a service area".
The latter is one among several possible strategies to achieve the
first.

>unique LIS client identity. These aren't, currently, part of the

What do you mean by LIS client identity?  If you mean the client requesting
the location, in what frame of reference is this going to be meaningful to
a PSAP?  Or do you really mean to take on the "vouch for the client" problem?
If you do, I note you likely don't have to do anything to vouch for the location
itself, as in that system you would have something directly traceable to the
attacker.  I am skeptical of that being developed or deployed, but having
both is just needless.

It is not at all clear how that would work, by the way, in a system in which
the immediate service supplier (my home network, Qualcomm's enterprise,
Peet's free wifi-using customer) validates the user's acceptance of the terms
of service, but the upstream validates the location.  There are lots of times
when there is no unique user identity there even at the "retail" level--
maybe a MAC address associated with a hotspot, but no user-level identity;
even where there is, the upstream is in no position to validate that identity,
as it is the customer's customer.

>If the signature applies to the whole object then this won't be

Adding  PIDF-LO objects with the changes and retaining the original
would be one way around that, but it consumes a lot of bytes.  If
you are going to permit proxies and recipients to change values,
though, any system based on the originator's signature will have this
problem.

>those policies manually; if you get to that point you've already lost.

You seem to believe that the only strategy is the one in place now.  That's
not an attitude that has worked in other efforts to thwart DDoS.  In particular,
it ignores the fairly substantial amount of work on pattern-based responses.
Those work off of the collection of attacking traffic, rather than individual
flows, and they might well work here for DDoS.  They will not thwart the
random call from the teenager in Tennessee to the PSAP in California,
playing an unfunny prank, but that is, honestly, not where I see the real
danger lying. It likely will help in thwarting the zombie-host network of
10k unpatched PCs trying to bring down a PSAP, and it will likely help a
lot more than forcing that PSAP into attempting the computationally
expensive work of validating the cryptographic signatures on objects
that were meant to be cachable and re-distributable in the first place.

			Ted

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 9 Mar 2007 19:57:46 -0600

I think that characterizing a PSAP the same as a web server and trying
to apply standard DDOS strategies to it will not work. Or rather, it
will work, but I think that it is not sufficient without additional
criteria being added to the heuristics and that includes an indication
of location source, time, and client device identity.

Client device identity - We've had this discussion several times already
on this list. I am not referring to the user identity; I am not
referring to a VoIP client identity. I am referring to the presence of
the device on the access network and the fact that, apart from working
out its location, the LIS can attribute a single identity to the target
it is calculating location for. This is an anonymous identity - it is
"identity" in its truest abstract sense - uniqueness.

The inclusion of this identity as part of the signature, allows the
automatic heuristics to detect multiple calls that are apparently coming
from the same target.

Yes - that's right, multiple devices on the other side of a NAT will
have the same identity as far as a LIS is concerned. That's a second
order discussion that speaks to how the heuristics need to operate. It's
also a factor in the question of whether an enterprise needs its own LIS
or not - just how many concurrent requests to a service is it reasonable
to expect it to be making (without it being reasonable that some of them
get deprioritized relative to emergency calls originating from other
locations).

In terms of signing just part of the PIDF-LO, the DSIG draft that has
been referenced a couple of times identifies those components that the
LIS has something to say about - primarily the location itself, and time
and the client identity (as described above). This is how it is
different to just using S/MIME.

An alternative is to use the assertion mechanism - the client proffers
its PIDF-LO, the LIS sets the bits that it is concerned about and then
signs the whole thing with S/MIME. That's consistent with using the same
mechanism to validate location obtained from link layer sources.
However, this still locks the rest of the content away from downstream
proxies.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Saturday, 10 March 2007 12:22 PM
To: Dawson, Martin; Andrew Newton; GEOPRIV WG
Subject: RE: [Geopriv] Where we are / are we with L7-LCP

>unique LIS client identity. These aren't, currently, part of the

What do you mean by LIS client identity?  If you mean the client
requesting
the location, in what frame of reference is this going to be meaningful
to
a PSAP?  Or do you really mean to take on the "vouch for the client"
problem?
If you do, I note you likely don't have to do anything to vouch for the
location
itself, as in that system you would have something directly traceable to
the
attacker.  I am skeptical of that being developed or deployed, but
having
both is just needless.

It is not at all clear how that would work, by the way, in a system in
which
the immediate service supplier (my home network, Qualcomm's enterprise,
Peet's free wifi-using customer) validates the user's acceptance of the
terms
of service, but the upstream validates the location.  There are lots of
times
when there is no unique user identity there even at the "retail" level--
maybe a MAC address associated with a hotspot, but no user-level
identity;
even where there is, the upstream is in no position to validate that
identity,
as it is the customer's customer.

>those policies manually; if you get to that point you've already lost.

You seem to believe that the only strategy is the one in place now.
That's
not an attitude that has worked in other efforts to thwart DDoS.  In
particular,
it ignores the fairly substantial amount of work on pattern-based
responses.
Those work off of the collection of attacking traffic, rather than
individual
flows, and they might well work here for DDoS.  They will not thwart the
random call from the teenager in Tennessee to the PSAP in California,
playing an unfunny prank, but that is, honestly, not where I see the
real
danger lying. It likely will help in thwarting the zombie-host network
of
10k unpatched PCs trying to bring down a PSAP, and it will likely help a
lot more than forcing that PSAP into attempting the computationally
expensive work of validating the cryptographic signatures on objects
that were meant to be cachable and re-distributable in the first place.

			Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 9 Mar 2007 21:05:29 -0500

> "identity" in its truest abstract sense - uniqueness.

Unless you are worried about lots of devices at one physical address  
(which are likely behind one NAT), I don't see how this adds  
significant value.

Also, the PIDF-LO already contains such an identity (entity), if you  
really want it.

Similarly, the validity periods is also already in PIDF (expires).

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 9 Mar 2007 22:30:03 -0600

The opposite - I'm concerned about just one device making lots of calls
using different CLIs and VoIP service identities. The LIS is capable of
marking the location objects as being associated with the same physical
device regardless of how they appear as phone calls. I have no problem
with using an existing information element as long as this use isn't
contrary to what that information element is intended for.

I'm not so sure about "expires". I would prefer to see the time at which
the location was actually associated with the device and let the
recipient apply their own policy about what constitutes expiry. Does the
profile have that.

Cheers,
Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 11 Mar 2007 17:52:09 -0500

I believe that using the entity attribute has already been proposed.

Henning, which of the plethora of PIDF standards contains "expires"?  3863 has a timestamp, but nothing of the "expires" nature.

M

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Saturday, 10 March 2007 3:30 PM
> To: Henning Schulzrinne
> Cc: Ted Hardie; GEOPRIV WG; Andrew Newton

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 11 Mar 2007 20:52:49 -0400

RFC 4481 has the equivalent of expiration functionality.

On Mar 11, 2007, at 6:52 PM, Thomson, Martin wrote:

> Henning, which of the plethora of PIDF standards contains  
> "expires"?  3863 has a timestamp, but nothing of the "expires" nature.
>

With that, the whole object can be signed, if desired.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 12 Mar 2007 17:00:52 -0700

>  existing system (which allows for attackers to call from within the service

I'm not sure that the a caller who posses a signed location is no 
more likely to be an attacker than is a caller with today's POTS, 
given that attackers can obtain a location from an area other than 
their own.

>  to be a matter of policy anyway.

So the question for geopriv becomes: what else is it necessary for us 
to do now?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Finagle's Second Law:
    No matter what the anticipated result, there will always be
    someone eager to (a) misinterpret it, (b) fake it, or (c)
    believe it happened according to his own pet theory.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 12 Mar 2007 17:07:26 -0700

>  If the signature applies to the whole object then this won't be

Just curious: what about providing two pidf-lo objects: one signed 
and unaltered, and one that was modified as needed.  The PSAP (or 
other entity) could compare the two and determine which fields had 
been modified, and decide if the fields were "safe".

-------------- Randomly-selected tag: ---------------
Beware of false knowledge; it is more dangerous than ignorance.

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 12 Mar 2007 19:12:24 -0500

I think the issue with that is that it tries to second guess the
application for the PIDF-LO.

SIP conveyance is just one scenario. A LIS client may request a location
object for any arbitrary application using any arbitrary conveyance. The
application may not deal with multiple PIDF-LO objects.

So - the proposition is that, in generating the signature on the
location information, the LIS is only securing those parts of the
information that it is taking responsibility for without impeding the
ability of other actors in the application scenario from making
appropriate contributions to the content of the object.

Cheers,
Martin

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 12 Mar 2007 19:14:02 -0500

It's not about the "likelihood" of being an attacker. The emergency
service is currently structured to receive calls from devices that are
physically located within the catchment area of the service. *One* of
the contributions of providing signed location (and it is just one of
them) is that a policy can be applied to imposes the same limitation.

Cheers,
Martin

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Tuesday, 13 March 2007 11:01 AM
To: Ted Hardie; Andrew Newton; GEOPRIV WG
Subject: Re: [Geopriv] Where we are / are we with L7-LCP

service
service

PSAPs
looking

-------------- Randomly-selected tag: ---------------
Finagle's Second Law: