[Gen-art] Re: [Ecrit] WG: Review of draft-ietf-ecrit-security-threats-04.txt
Henning Schulzrinne <hgs@cs.columbia.edu> Mon, 20 August 2007 16:02 UTC
Return-path: <gen-art-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9hm-0008Po-ME; Mon, 20 Aug 2007 12:02:14 -0400
Received: from gen-art by megatron.ietf.org with local (Exim 4.43) id 1IN9hk-0008PR-VQ for gen-art-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 12:02:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9hk-0008PJ-Lb; Mon, 20 Aug 2007 12:02:12 -0400
Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN9hi-0000Zu-Kr; Mon, 20 Aug 2007 12:02:12 -0400
Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l7KG27WF009308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Aug 2007 12:02:08 -0400 (EDT)
In-Reply-To: <46C9B81A.5020101@gmx.net>
References: <46C4B6C5.1040905@gmx.net> <46C9B81A.5020101@gmx.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <23CDC6F8-2B42-4257-9D39-48FF072F2B3E@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Mon, 20 Aug 2007 12:02:39 -0400
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
X-Mailer: Apple Mail (2.752.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
X-Spam-Score: -1.0 (-)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: christian.vogt@nomadiclab.com, gen-art@ietf.org, ECRIT <ecrit@ietf.org>
Subject: [Gen-art] Re: [Ecrit] WG: Review of draft-ietf-ecrit-security-threats-04.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org
Just to add to this: I think we should state explicitly that we're not trying to solve all security problems related to emergency services. False dispatch is unlikely to be something that we can reasonably address; the best we can do is say that next-generation systems may make checking on incident reports easier. For example, a call taker might be able to easily see the picture on a surveillance camera for the area, to see if there smoke where there's supposed to be a large fire. In the UK, this presumably will capture just about any corner of the cities. (Whether that's desirable from a privacy perspective is probably best left to other discussion forums.) From what I can tell, good call takers also develop a hunch that the giggling teenager may deserve an additional question or two before sending a fire truck. Having additional site information may also allow the call taker to ask questions. If you have the new Google street-level views, you can ask "what store is this accident next to?" or you can see that the supposed house fire is in an open field. In many cases, sending a squad car to check things out is a much better choice than not responding, since the consequences of that may be dire. All of this is well beyond what a protocol working group can do. We shouldn't promise to solve all the emergency services world's security problems. On Aug 20, 2007, at 11:49 AM, Hannes Tschofenig wrote: > > The future emergency services infrastructure might be able to > handle more media types and accept additional data. However, it is > quite likely that the PSAP operator will not be able to use these > things for a long time since the capabilities are just not > supported by end systems and in some cases it might actually be > difficult to expect the emergency caller to take pictures (given > the level of stress they are likely to experience during an > emergency situation). > > Finally, an adversary can easily exploit such a system by not > attaching videos or pictures since the emergency call will not > rejected anyway. > > I think the best we can hope for at the moment is that the > capabilities built into SIP are used to a maximum extent and that > the PSAP operator accepts supplementary data about the emergency > scene. > > We are, to some extend, trying to capture some of these attacks. > Our focus was more on the attack against the PSAP itself when faked > location information was used. We have published a few documents on > this subject already, see http://www.tschofenig.com/wp/?p=131. We > hope to make some progress on that topic as well since it appeared > to be a difficult one. > > Ciao > Hannes > >> >> Best regards, >> - Christian >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Re: [Ecrit] WG: Review of draft-ietf-ec… Hannes Tschofenig
- [Gen-art] Re: [Ecrit] WG: Review of draft-ietf-ec… Henning Schulzrinne
- [Gen-art] Re: [Ecrit] WG: Review of draft-ietf-ec… Christian Vogt
- [Gen-art] Re: [Ecrit] WG: Review of draft-ietf-ec… Hannes Tschofenig
- [Gen-art] Re: [Ecrit] WG: Review of draft-ietf-ec… Christian Vogt