Subject: Re: [dispatch] Comments on draft-schulzrinne-dispatch-callinfo-spam-00

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 9 Dec 2016 19:18:21 +0000

Keith,

Thank you for your extensive comments. I'm creating -01, with comments inline.

________________________________
From: dispatch <[email-masked]> on behalf of Drage, Keith (Nokia - GB) <[email-masked]>
Sent: Monday, October 10, 2016 10:38 AM
Subject: [dispatch] Comments on draft-schulzrinne-dispatch-callinfo-spam-00

1)      Section 1, 1st paragraph, uses the term "illegal telemarketing" but the abstract just says "telemarketing". I assume both legal and illegal telemarketing would fall in scope.

>> Noted.

2)      Section 1, and section 3. I think any use of the term "emergency" needs to distance itself from any emergency call in for example "112" or "911" usage. I would not expect this capability to be used on such emergency calls, if there is additional data to be provided on such calls, then we have a defined way of doing that.

>> -01 will clarify that this is related to alerts and warnings, not 911/112. The term "reverse 911" is sometimes used, but it is a trademark for a specific product.

3)      Section 1: Text "The Call-Info header field MAY be signed
   using a future "ppt" extension to [I-D.ietf-stir-rfc4474bis].  To
   ensure that an untrusted originating caller does not mislead the
   called party, a new feature tag, sip.call-info.spam, indicates
   whether the terminating carrier will remove untrusted information."

I don't know whether it is intended to define this in the timeframe of this i-d. If yes, then I assume it will be replaced by a normative reference later in the document. If no, I suggest it is removed, as we should not really hint that future work plan that may or may not exist.

>> This is a question to the STIR crowd on my part: Is any extension work needed or can the signing already be done? From what I can tell, stir-passport-extensions. My suggestion would be to do this as a separate draft once 4474bis has shipped.

4)      Section 1: I would suggest avoing the use of normative language in section 1, which is labelled introduction, particularly as in this case it comes before section 2 which contains the RFC 2119 language. These requirements need to appear later in the document.
>> I have moved the operational material from the introduction into a new section.

5)      Section 1:

"   SIP entities MUST add a new Call-Info header field, rather than add
   parameters to an existing one.  There MAY be several Call-Info header
   fields in one request."

It is not clear to me whether multiple generators of Call-Info header field parameters in accordance with this draft along the call path would create multiple Call-Info header fields, or would be permitted to combine them into one Call-Info header field. Given that there is no indication of which entity generated the data, it probably does not matter that they have to be separate Call-Info header fields, only that they are distinct from other Call-Info header field usages.
>> My text is unclear. What I meant was that the entity 'b' should do something like (assuming the first line was already there)
Call-Info: <url> ;purpose=info; spam=0.95; source="a.example.com",
Call-Info: <url> ;purpose=info; type="fraud"; source="b.example.com"
Rather than
Call-Info: <url> ;purpose=info; spam=0.95; source="a.example.com"; type="fraud"; source="b.example.com"
(leaving aside whether you could even do that in this case, given the parameter duplication).

I will try to amplify, but please take a look to see if I succeeded.

6)      Section 3: Values with parameters and types. There are hints that certain parameters carry values, eg. "spam" with a percentage, but no indication of how the syntax of this works.
>> I have added an ABNF section.

7)      Section 3: There are other parameters and types that could well carry values, such as "business" which could be followed by a company name of business registration number. Obviously that may sometimes apppear in the From or Calling Party ID, but there may be instances where more specific and different information would be inserted there.
>> To keep complexity low and avoid non-standard syntax (type=business="EIN"), I would suggest adding a suitable field if that should be desired. There are several plausible ones; for example, in the US, you could have a local state license number, e.g., for contractors, or the FEIN (Federal Employer Identification Number, the "social security" number for businesses) or, for banks, the mortgage lender number. Or it could be the DUNS (Dun & Bradstreet number, assigned to just about any entity). Thus, since you can't easily tell by looking at the number what kind of identifier this is, it seems to make more sense to define them as parameters. However, I suspect that a better option is to use the extended CNAM model, i.e., a vCard reference.

8)       Section 3. "spam" appears both as a parameter in its own right, and as a "type" Under what conditions do you expect one versus the other to be used?

>> Good question. Sometimes, the inserting entity will have only spam-likelihood information, sometimes only type information, sometimes both. For example, a charity or political may still be considered unwanted, with a non-zero spam rating, based on crowd sourced information. This allows some differentiation - I may decide to accept a charity call even though it has a non-zero spam rating. I have added a bit of text.

9)      Section 5: For types, Section 3 states "Additional labels are registered with IANA." However there seems to be no registration of the values defined under types.
>> I have added an IANA registration section.

10)     Section 6. The mechanism defined in the security considerations does not cater for spoofing by MITM attackers between the registrar and the UA. Additional security that uses the same security tunnel for both the REGISTER and the subsequent messages would be needed for that.

>> I'm not sure I fully understand this comment. Are you saying that SIP-over-TLS would be needed to prevent a MITM to insert bogus information? Wouldn't this be the same problem as for (say) verstat or indeed any of the other REGISTER feature capabilities, at least the ones that may have security-relevant properties? For now, I'll add a note about possible MITM attacks and elaborate as I better understand the concern and possible specific solutions.

Keith

>> Henning

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