A SIP Response Code for Unwanted Calls
draft-ietf-sipcore-status-unwanted-06
Yes
(Ben Campbell)
(Terry Manderson)
No Objection
(Alexey Melnikov)
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Suresh Krishnan)
Note: This ballot was opened for revision 05 and is now closed.
Adam Roach Former IESG member
Yes
Yes
(2017-04-25 for -05)
Unknown
See also Brett Tate's comment about which document to reference for call transfer: https://www.ietf.org/mail-archive/web/sipcore/current/msg07898.html
Ben Campbell Former IESG member
Yes
Yes
(for -05)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2017-04-26 for -05)
Unknown
I agree with Warren - short, clear, and to the point.
I agree with EKR and Kathleen about requiring authentication.
In this text,
Thus, the call is rejected due to the called party's
(temporary) disposition.
I'm having trouble matching dictionary definitions to the use of "disposition" here. I guess it's an OK use of the word, and I know what's intended based on context clues, but if another word would be clearer, that would be helpful.
This text,
The particular response code number
was chosen to reflect the distaste felt by many upon receiving such
calls.
is unchanged from the previous version, where the response code number was 666. Is that intentional?
Just checking - in this text,
The service
provider delivering calls or messages to the user issuing the
response MAY take a range of actions, for example, add the calling
party to a personal blacklist specific to the called party, use the
information as input when computing the likelihood that the calling
party is placing unwanted calls ("crowd sourcing"), initiate a
traceback request, or report the calling party identity to consumer
complaint databases operated by government authorities.
there's no standardized way for the called party to signal that this action should be reversed, is there? I ask, because the next paragraph says,
The user experience is envisioned to be somewhat similar to email
spam buttons where the detailed actions of the email provider remain
opaque to the user.
and I use the "this is not spam" button on email fairly frequently. The security considerations section does talk about the protected party notifying the service provider using unstandardized mechanisms - I see that. Maybe a forward pointer to that discussion would be helpful.
Terry Manderson Former IESG member
Yes
Yes
(for -05)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -05)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -05)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -05)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -05)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -05)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -05)
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
(2017-04-24 for -05)
Unknown
It seems like the security considerations here probably need to cover what's needed to prevent forged 607 responses. This seems like an issue for on-path attackers, who could block the real response and inject a 607. This isn't usually that great an attack, but if you can use it in a sort of bounce attack to really gag a sender, that would be bad. Probably what's needed here is text about only accepting 607s over TLS (and filtering at the other endpoint). It's also worth mentioning that in a post-STIR world, you could send the PASSporT object as proof of the existence of the call (though not of its unwantedness).
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2017-04-25 for -05)
Unknown
I agree with EKR's comment and would like to see additional security considerations that spell out the dangers of not sending this over secure network or without mutual authentication (MiTM attack he describes). I just noticed the text called out by the SecDir review and would like to know if the following change could be made since it is just part of a list of examples: OLD: or report the calling party identity to consumer complaint databases operated by government authorities. NEW: or report the calling party identity to consumer complaint databases. It doesn't seem necessary to call out government authorities here and there is the potential for abuse with such databases (government or otherwise managed). I was glad to see the explanation for the existence of this draft in the shepherd report and ballot text, but think the explanation should be in the draft as well. I was curious about implementations as there is the potential for trouble with this option. It seems like it should be experimental first, but I guess we could always make it historic later if unforeseen problems arise.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-04-24 for -05)
Unknown
I actually have one mostly technical question: It is not fully clear to me if the Unwanted response code always indicates a user action or if the same code is used when an automated system declines the call? My understanding is that the idea is that this could also be automated if the user has some kind of control of the system (which is probably hard to verify). Or would it make sense to distinct between the cases where the user actively rejects a call or an automated system is generating the response code (on behalf of the user)?
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -05)
Unknown
Warren Kumari Former IESG member
No Objection
No Objection
(2017-04-23 for -05)
Unknown
Thanks, short, sweet and to the point. One minor comment: "These may use call characteristics such as call duration and call volumes for a particular caller, as well changes in those metrics over time" s/as well changes/as well as changes/ (missing a word) Please also see Al Morton's OpsDir comment at: https://www.ietf.org/mail-archive/web/ops-dir/current/msg02571.html (for an earlier version)