Subject: [sipcore] Eric Rescorla's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Apr 2017 12:18:38 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-sipcore-status-unwanted-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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).

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 24 Apr 2017 20:10:13 +0000

In order to be effective, you'd have to be able to intercept lots of destinations (since the spammer is likely not reaching all destinations that the attacker may have access to). If the attacker has that kind of in-band access, why not just block the calls directly with any 4xx/5xx/6xx response?

For most commercial VoIP networks (say, residential cable networks or LTE), the attacker would have to compromise the link-level encryption or install itself on the end system. (In the latter case, game over, even with TLS.)

Obviously, TLS is a good idea, but I suspect that making it MUST strength would essentially preclude the deployment of the mechanism in most commercial networks.

I do believe that pointing out the potential issue is worthwhile. Any text suggestions would be helpful.

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Monday, April 24, 2017 3:19 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Adam Roach <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Eric Rescorla's No Objection on draft-ietf-sipcore-status-unwanted-05: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=R-ExbCjN2Iez-mZLcWFWH7ctNykRX9QT8S9srcsIRWg&s=fbA_g7t18zuJQIV-s9kewlLScLl1hh3q7dkdIr2Kn-o&e=
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=DwICaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=R-ExbCjN2Iez-mZLcWFWH7ctNykRX9QT8S9srcsIRWg&s=wCmDT9gXboJAniXB1AeiaDmkEKA4Sb3DHt7CXDhIgUM&e=

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Apr 2017 13:17:46 -0700

On Mon, Apr 24, 2017 at 1:10 PM, Henning Schulzrinne <
[email-masked]> wrote:

> In order to be effective, you'd have to be able to intercept lots of
> destinations (since the spammer is likely not reaching all destinations
> that the attacker may have access to). If the attacker has that kind of
> in-band access, why not just block the calls directly with any 4xx/5xx/6xx
> response?
>

Because it's a one-time attack that has persistent effects.

My model here is you have some situation where there are a lot of legit
robocalls
(e.g., for political polling) and the attacker controls some of the
networks and
so forges a lot of 607s. This gets pushed back to the carrier for the
robocaller
and they get gagged. You don't need all the networks to have a negative
impact.

For most commercial VoIP networks (say, residential cable networks or LTE),
> the attacker would have to compromise the link-level encryption or install
> itself on the end system. (In the latter case, game over, even with TLS.)
>
> Obviously, TLS is a good idea, but I suspect that making it MUST strength
> would essentially preclude the deployment of the mechanism in most
> commercial networks.
>

Well, TLS or not, it's actually a pretty terrible idea to accept 607s
unless you are receiving them over a secure network. Regardless of whether
there is 2119 normative text, the document should make clear the
consequences of it, which are bad.

-Ekr

I do believe that pointing out the potential issue is worthwhile. Any text
> suggestions would be helpful.
>
> Cc: [email-masked]; Adam Roach <
> [email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=
> y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYR
> Hfarpk4MK59RE&m=R-ExbCjN2Iez-mZLcWFWH7ctNykRX9QT8S9srcsIRWg
> &s=fbA_g7t18zuJQIV-s9kewlLScLl1hh3q7dkdIr2Kn-o&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__
> datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-
> 2Dstatus-2Dunwanted_&d=DwICaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=
> FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=R-ExbCjN2Iez-
> mZLcWFWH7ctNykRX9QT8S9srcsIRWg&s=wCmDT9gXboJAniXB1AeiaDmkEKA4Sb
> 3DHt7CXDhIgUM&e=
>
>
>