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

From: "Stastny Richard" <[email-masked]>
Date: Wed, 7 Sep 2005 16:48:01 +0200

> 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).

I have no problems with this approach, this is perfectly valid in
the architecture und up to the national implementations. 
This approach will be needed anyway as long as
you need to have a local mapping to PSAPs connected via
the PSTN or want to funnel the whole thing in a special
private network.

On the other hand, as Henning pointed out, designers of
such special emergency networks should consider where the threats
really are, what they gain and what they loose. I think there is
still some work to do in tutorials and consulting

Richard

> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, September 07, 2005 4:32 PM
> To: Stastny Richard; 'Andrew Newton'
> Cc: 'ECRIT'
> Subject: RE: [Ecrit] Emergency Context Routing of
InternetTechnologies-
> Architecture Considerations
> 
> 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-
> 
> > -----Original Message-----
> > 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
> >
> > > -----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

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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 7 Sep 2005 15:40:25 -0400

I am only suggesting that transparency in government operations is a
good thing.

The secrecy and security that was proposed earlier on this thread
appeared to be focusing more on legal CYA than on real security.  So,
the threats need to be well specified, but keeping the public in the
dark about how this service is provided is not one of them.

Mike

> Sent: Wednesday, September 07, 2005 3:14 PM
> To: Michael Hammer (mhammer)
> Cc: Henning Schulzrinne; Stastny Richard; ECRIT
> Subject: Re: [Ecrit] Emergency Context Routing of 
> On Sep 7, 2005, at 2:42 PM, Michael Hammer ((mhammer)) wrote:
> 
> > As a matter of fact, when I moved into a newly built community, the 
> > insurance company wanted to know where the nearest fire station was.
> 
> That's fairly standard for purchasing homeowners insurance.
> 
> > The local fire and police also needed to change their habits to 
> > occasionally drive through the community to learn the street 
> > addresses.
> 
> I cannot speak to the habits and practices of Arlington 
> County's fire and police services.  Absent any details, I am 
> hesitant to tell them how to do their job.
> 
> > (Taxi drivers and pizza delivery took a while to learn also.)
> >
> > Bottom line, if I was in a PSAP dead spot, as well as a 
> cell coverage 
> > dead spot, shouldn't I know that?
> 
> Sure.  Though I have no idea what that has to do with this thread.   
> Save any implementation boogs, I cannot understand how f(x) = 
> 0 calculated in an end device is any more useful than f(x) = 
> 0 calculated in an ESRP or mapping server.
> 
> > Arguing that we shouldn't be prepared for that possibility is as 
> > foolish as the lack of local planning for Katrina.  
> Governments should 
> > be held accountable.  This is just an extension of that.
> 
> Who is arguing this?  Because I said no such thing.  However, 
> making governments accountable is outside the scope of any 
> IETF working group.
> 
> -andy
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 8 Sep 2005 09:53:59 -0400

On Sep 8, 2005, at 8:46 AM, Brian Rosen wrote:

> 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.

First, there is a difference between "secret" and "easily  
accessible".  As I stated before, just because bad actors can figure  
out this information from other sources doesn't mean it should be  
given to them.

 From Nate's message:

> If I know
> the boundaries of the Derby PSAP, I could create a PSTN based DoS  
> attack
> anywhere from within that boundary (potentially 50 miles from Island
> Pond).

and

> But that does not
> help in the interim between here and there when someone gets their  
> hands
> on the PSAP boundaries and realizes the attacks they can initiate  
> using
> the PSTN DoS approach.

I did not read that as "there should be no concern for the  
dissemination of the PSAP's boundary information."

Echoing back to something Henning said:

> 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.

There is a difference between dissemination of the PSAP boundary  
information to a limited set of aggregators, mirrors, and/or  
responsible entities and dissemination of the PSAP boundary  
information to anybody with an Internet connection.

-andy