[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