Subject: Re: [stir] I-D Action: draft-ietf-stir-threats-01.txt

From: Travis Russell <[email-masked]>
Date: Thu, 6 Feb 2014 20:18:17 -0800 (PST)

FYI - I am leaving Dubai today after a week of discussions at the GSMA Fraud Forum meetings here. This topic of SIP spoofing comes around quite a bit within this group as these are the folks who have to deal with the fall-out. Might be a good group to review the finished document as they understand the issues and business implications better than anyone. If that is of interest to the group let me know and I can help facilitate.

----- Original Message -----
From: [email-masked]
To: [email-masked], [email-masked]
Sent: Thursday, February 6, 2014 11:00:07 PM GMT +04:00 Abu Dhabi / Muscat
Subject: Re: [stir] I-D Action: draft-ietf-stir-threats-01.txt

Thanks for these notes, Paul.

>Section 1 - Use of 'Caller ID' to mean the name of the calling party:
>
>Maybe I have the wrong understanding, but I consider the term "Caller
>ID" to describe the delivery of the calling party number, or perhaps
>both the number and optionally the name. I find it quite confusing to
>see it used to mean just the delivery of the name, not the number.
>
>ISTM it would be better to use Caller ID to refer to the calling party
>number, and another term for the calling party name.
>
>Wikipedia says: "Caller ID is made up of two separate pieces of
>information: the calling number and the billing (or subscriber) name
>where available." So that must be right. :-)

Yeah, we¹re trying to keep that straight, so I¹ll replace any lingering
misreferences to Caller ID with CPN.

>Section 3.2 says:
>
>    When a human callee is to be alerted at call setup time, the time
>    frame for executing any countermeasures is necessarily limited.
>    ...  For text
>    messages, a delay for executing anti-impersonation countermeasures is
>    much less likely to degrade perceptible service.
>
>IMO this is frequently not the case. Often SMS-style text messages are
>used in an interactive conversation style. In that case I suspect that
>the delay sensitivity is similar to that for call setup type.

Hmm. My intuition would be the other way. If you have to wait, say, ten
seconds after receiving a call before you start alerting the callee, the
caller may hang up - whether you¹re playing ringing audio to the caller
that whole time or (worse, I think) just dead air, they may lose patience.
But if I¹m getting a text message for the first time from an unfamiliar
source, I don¹t mind if its delivery is delayed ten or twenty seconds, if
that will cut down significantly on spam. SMS delivery is unreliable, and
senders are accustomed to not receiving immediate responses.

In text message conversations where there¹s quick back-and-forth, that
delay might be intolerable, sure. But in those cases both parties have
already established that they are participating in desired communications.
So from a mechanism perspective, this is a case where you wouldn¹t have to
acquire new credentials, check delegation chains or what have you for each
incoming message, provided messages from the same source use the same
credentials. 

Make sense?

>Otherwise this seemed good to me.

Thanks again,

Jon Peterson
Neustar, Inc.

>	Thanks,
>	Paul
>
>On 2/5/14 2:45 PM, Robert Sparks wrote:
>> I'm working on the shepherd writeup for this draft.
>>
>> I'd like to hear from those that provided comments that they believe
>> their comments have been addressed.
>>
>> I'd also very much like to hear from more people in the group that they
>> read the document and believe it is ready to ship.
>>
>> RjS
>>
>> On 2/4/14, 6:48 PM, [email-masked] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>   This draft is a work item of the Secure Telephone Identity Revisited
>>> Working Group of the IETF.
>>>
>>>          Title           : Secure Telephone Identity Threat Model
>>>          Author          : Jon Peterson
>>>     Filename        : draft-ietf-stir-threats-01.txt
>>>     Pages           : 11
>>>     Date            : 2014-02-04
>>>
>>> Abstract:
>>>     As the Internet and the telephone network have become increasingly
>>>     interconnected and interdependent, attackers can impersonate or
>>>     obscure calling party numbers when orchestrating bulk commercial
>>>     calling schemes, hacking voicemail boxes or even circumventing
>>>multi-
>>>     factor authentication systems trusted by banks.  This document
>>>     analyzes threats in the resulting system, enumerating actors,
>>>     reviewing the capabilities available to and used by attackers, and
>>>     describing scenarios in which attacks are launched.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-stir-threats/
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-stir-threats-01
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-stir-threats-01
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> stir mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/stir
>>
>> _______________________________________________
>> stir mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/stir
>>
>
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

-- 

Oracle
Travis Russell | Technologist | 
+1919.460.2172 (o) | +1919.412.1167 (c) 

Oracle CGBU Product Marketing 
5200 Paramount Pkwy 
Morrisville, NC 27560 
USA 

Green Oracle	Oracle is committed to developing practices and products that help protect the environment