Subject: RE: [Ecrit] Emergency Context Routing of Internet Technologies-Architecture Considerations

From: "Stastny Richard" <[email-masked]>
Date: Wed, 7 Sep 2005 15:58:02 +0200

I still do not see why knowing the boundaries
of a PSAP region poses a security problem at all.

This is the same like knowing the boundaries of
a district or state. Everybody can have access
to this information (read-only). It is public
knowledge anyway.

Of course having R/W access is another issue,
but this is not an ecrit problem

Richard

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Wednesday, September 07, 2005 3:49 PM
> To: Stastny Richard
> Cc: ECRIT; Winterbottom, James; James M. Polk
> Subject: Re: [Ecrit] Emergency Context Routing of Internet
Technologies-
> Architecture Considerations
> 
> 
> On Sep 7, 2005, at 8:17 AM, Stastny Richard wrote:
> 
> > What is the problem with making the polygons publicly visible?
> 
> It may be considered a security problem.  Yes, trying to keep
> polygons out of sight is not a perfect or total security solution.
> But that doesn't mean you should make things easy for the bad
> actors.  And if there is any one take away we should have learned
> from protocol design, it is that the perfect security solutions tend
> to be the ones that never get implemented.
> 
> > Regarding the URIs:
> > If you want the terminal to reach emergency services,
> > you have to give them a URI. Providing them an indirect
> > URI just shifts the problem, but does not solve it.
> 
> I agree.
> 
> -andy

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Sep 2005 10:30:27 -0400

I agree with Richard. There is real cost in obscurity; as Richard  
points out, at least in the US, the information is essentially public  
anyway, so hiding this simply means that bugs won't be found, that  
systems are made more complicated and that there's more opportunity  
for various security consultants and contractors offering their snake- 
oil services to gauge PSAPs. We all pay the price for pseudo- 
security, even if it just confiscated nail clippers at the airport...

I'm very afraid that this type of recommendation will be used to  
design closed, non-debuggable, expensive systems. Unless there is a  
strong engineering motivation that can be justified on technical  
grounds, we should not make such recommendations.

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 7 Sep 2005 10:31:36 -0400

Richard,

NENA has expressed a requirement to have the ability to *hide* the PSAP
boundaries from public view for security reasons.  Ideas discussed to date
have included having a single URI per state with finer-grain routing
performed behind this state-level *demarc* in a private/protected Emergency
Services Network (ESN).

Imagine this as a large corporate network that has one/more Internet
connections to their internal network(s).  You don't know my actual email
[email-masked] is the 'public' view.

So, all VoIP callers within (for example) the state of New York, may all use
the same URI for emergency calling, accessing a b2bua/firewall at a single
point into the private ESN.  I realize this *could* be accomplished by
having the user know the actual destination PSAP uri, but this *could* also
be accomplished using a single uri for New York with eventual secondary
routing.

-Marc-

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Stastny Richard
> Sent: Wednesday, September 07, 2005 9:58 AM
> To: Andrew Newton
> Cc: ECRIT
> Subject: RE: [Ecrit] Emergency Context Routing of 
> InternetTechnologies-Architecture Considerations
> 
> I still do not see why knowing the boundaries of a PSAP 
> region poses a security problem at all.
> 
> This is the same like knowing the boundaries of a district or 
> state. Everybody can have access to this information 
> (read-only). It is public knowledge anyway.
> 
> Of course having R/W access is another issue, but this is not 
> an ecrit problem
> 
> Richard
> 
> > It may be considered a security problem.  Yes, trying to 
> keep polygons 
> > out of sight is not a perfect or total security solution.
> > But that doesn't mean you should make things easy for the 
> bad actors.  
> > And if there is any one take away we should have learned 
> from protocol 
> > design, it is that the perfect security solutions tend to 
> be the ones 
> > that never get implemented.
> > 
> > > Regarding the URIs:
> > > If you want the terminal to reach emergency services, you have to 
> > > give them a URI. Providing them an indirect URI just shifts the 
> > > problem, but does not solve it.
> > 
> > I agree.
> > 
> > -andy
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 7 Sep 2005 11:07:10 -0400

On Sep 7, 2005, at 10:30 AM, Henning Schulzrinne wrote:

> points out, at least in the US, the information is essentially  
> public anyway, so hiding this simply means that bugs won't be  
> found, that systems are made more complicated and that there's more  
> opportunity for various security consultants and contractors  
> offering their snake-oil services to gauge PSAPs. We all pay the  
> price for pseudo-security, even if it just confiscated nail  
> clippers at the airport...

Henning, you've mischaracterized the technical aspect of this.   
Polygons are data, not algorithms.  Do you expect of find a bug in a  
polygon that totally destroys the security of an ECRIT system?  At  
worst, the polygon may have a bad point or two... something that I do  
not think will give an attacker any advantage and something that can  
be easily corrected once discovered.  And this type of mistake seems  
most likely to be discovered by the PSAP and associated first  
responders and not the general public.

> grounds, we should not make such recommendations.

Having the polygons stay server-side does not equate to a closed  
system.  It is a design choice.  The protocols can still be open.   
And if the PSAP operators wish, they can demand standards on the back- 
side to give them more choice (though, this is out of scope for ECRIT).

Beyond the security aspect, there is also a deployment consideration  
in keeping the polygons server-side.  What if vendor Acme distributes  
an ECRIT capable end-device that has a bug in its intersection  
algorithm caused by some "clever" code optimization.  What if there  
are two such vendors with two different bugs.  The compensation to  
deal with such bugs will be difficult.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 07 Sep 2005 22:21:26 -0400

Andrew Newton wrote:
>> for various security consultants and contractors  offering their 
>> snake-oil services to gauge PSAPs. We all pay the  price for 
>> pseudo-security, even if it just confiscated nail  clippers at the 
>> airport...
> 
> 
> not think will give an attacker any advantage and something that can  be 
> easily corrected once discovered.  And this type of mistake seems  most 
> likely to be discovered by the PSAP and associated first  responders and 
> not the general public.

This has little to do with algorithms vs. data. Making polygons 
available, it allows third parties to aggregate data, for example, or to 
discover larger overlaps (and gaps).

By the way, data hiding is largely futile, even if it made sense to 
begin with: Assuming that this was super-secret information, The Bad Guy 
can simply generate test calls probing the boundaries and get a very 
good idea on where the bounds are or who serves a particular point in 
space, at least to the precision that The Bad Guy cares about.

> system.  It is a design choice.  The protocols can still be open.   And 
> if the PSAP operators wish, they can demand standards on the back- side 
> to give them more choice (though, this is out of scope for ECRIT).

As ECRIT, we should take no position on this issue, as there is no 
technical advantage to hiding the information. Indeed, if anything, it 
prevents certain caching architectures that one might want to layer on 
top of the infrastructure for increased resiliency or verification.

> 
> Beyond the security aspect, there is also a deployment consideration  in 
> keeping the polygons server-side.  What if vendor Acme distributes  an 
> ECRIT capable end-device that has a bug in its intersection  algorithm 
> caused by some "clever" code optimization.  What if there  are two such 
> vendors with two different bugs.  The compensation to  deal with such 
> bugs will be difficult.

I am not advocating that end systems do polygon intersection. This is an 
orthogonal issue. However, in a multi-layered, hierarchical system, such 
as the one we've been discussing at the interim and elsewhere, access to 
polygon information is extremely helpful, and possibly necessary for 
efficiency, for other servers in the hierarchy.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 8 Sep 2005 06:30:10 -0400

On Sep 7, 2005, at 10:21 PM, Henning Schulzrinne wrote:

> technical advantage to hiding the information.

Your perception of this being a technical advantage does not mean a  
real-world requirement should be ignored.  If the ECRIT solution is  
to be deployed, PSAP operators will have to be comfortable with it.   
We should not forget the lessons of DNSSEC, where the real-world  
requirements of privacy laws were dismissed as having no technical  
advantage resulting in stalled deployments by many TLD operators.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 8 Sep 2005 08:46:53 -0400

Nate Wilcox is the only PSAP person here, and he told you what the issue is.
The data isn't secret, there is a concern for how the data can be used for a
DoS attack.  The requirement is to avoid DoS attacks as much as possible,
not to keep service areas secret.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andrew Newton
Sent: Thursday, September 08, 2005 6:30 AM
To: Henning Schulzrinne
Cc: Stastny Richard; ECRIT
Subject: Re: [Ecrit] Emergency Context Routing of
InternetTechnologies-Architecture Considerations

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 08 Sep 2005 08:53:54 -0400

I can only echo Brian's message.

The only requirement I have heard so far is not directly making the 
*URI* for the PSAP itself visible, to make DOS attack prevention easier. 
This is a wholly separate and orthogonal issue.

As far as I know, the only laws likely to apply here are open-records 
and freedom-of-information laws (which obviously state exactly the 
opposite of your implication).

Andrew Newton wrote:
> real-world requirement should be ignored.  If the ECRIT solution is  to 
> be deployed, PSAP operators will have to be comfortable with it.   We 
> should not forget the lessons of DNSSEC, where the real-world