[sipcore] AD Evaluation of draft-ietf-sipcore-callinfo-spam-03

[Ben Campbell <[e-mail]>]

Hi,

This is my AD Evaluation of draft-ietf-sipcore-callinfo-spam-03. I have one major comment, and a few minor and editorial comments. I’d like to resolve the major comment prior to IETF last call.

Thanks!

Ben.


*** Major Comments ***

The draft needs to better describe the trust model. Currently, it says that a UA must ignore any spam parameters unless the registrar included the Feature-Caps tag. That implies the UA trusts the SIP service to label spam; I’m not sure that will always be true.

Likewise, it’s not clear to me when the callee’s SIP service might trust spam labeling from the caller’s service or some intermediary between them. I expect that we will see bad actors label everything as “government” or “health”. There’s a mention of signing the parameters, but that’s dependent upon a hypothetical STIR extension that may or may not exist.

Perhaps the best we can do is say the callee’s service needs to use it’s own local policy to decide what to trust. Even then, do we expect at least TLS integrity protection of the spam parameters between the caller and callee services? Do we expect calling number authentication  (i.e. STIR)?

I don’t mean to say that I know what the right answers are here, but I think the security considerations need to at least document the assumptions and potential issues or vulnerabilities, especially if there’s a risk of attackers tampering with the labels.

*** Minor Comments ***

§2: Is there a reason not to use the new boilerplate from RFC 8174? There are a few lower case instances of “may”; these are ambiguous under the original 2119 boilerplate.

§3: I don’t think it is appropriate to use a normative MAY when talking about a hypothetical future passport extension that may or may not ever happen.

Also, the reference for passport (ppt) should be RFC 8225.

§4, definition of “reason”: The definition describes extended information, not the “reason” in the normal sense of the term. In particular, I would normally expect a reason phrase to be human-readable, which would have i18n considerations. Is it too late to call this something different?

§5:
-  definition of “informational”: It’s not clear to me if the calling party is supposed to believe that a business relationship exists, or if it “is believed to” have such a relationship by whatever inserts the label. If the latter, how would it know? (This relates to my major comments about the trust model).

- definition of “spoofed”: How does this interact with STIR?

§11.2: Depending on the resolution of my major comments, the reference to 4474bis (now RFC8224) may need to be normative.

*** Editorial Comments ***

§1, 1st paragraph, “but unwanted callers may not provide their true name or use a name that
misleads”: I suggest “... may not provide their true name or _may_ use a name that misleads...” to avoid ambiguity about whether the “not” applies to both alternatives or just the first.

§3:
- first paragraph, "This document describes a new set of optional parameters and usage
for the SIP [RFC3261] Call-Info header field, purpose "info", for
labeling the nature of the call.”: I suggest ‘...with a purpose of “info...” ‘

- Third paragraph, "MAY be several Call-Info header instances”: That “MAY” seems like a statement rather than permission.

§6.2: The heading says “INVITE request”, but the contents are not an INVITE request. I assume it’s intended to be a Caller-Info header field as it might appear in an INVITE request? If so, please say that explicitly.