[sipcore] Security issue in -keep-08

Robert Sparks <rjsparks@nostrum.com> Tue, 23 November 2010 19:59 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id EC15F28C10B for <sipcore@core3.amsl.com>; Tue, 23 Nov 2010 11:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.15
X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MANGLED_PILL=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id EIGNJiUkJd6D for <sipcore@core3.amsl.com>; Tue, 23 Nov 2010 11:59:30 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7564D28C0FE for <sipcore@ietf.org>; Tue, 23 Nov 2010 11:59:28 -0800 (PST)
Received: from [] (pool-173-71-48-4.dllstx.fios.verizon.net []) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oANK0Mum094960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Nov 2010 14:00:22 -0600 (CST) (envelope-from rjsparks@nostrum.com)
From: Robert Sparks <rjsparks@nostrum.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Nov 2010 14:00:21 -0600
Message-Id: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com>
To: SIPCORE <sipcore@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Received-SPF: pass (nostrum.com: is authenticated by a trusted mechanism)
Subject: [sipcore] Security issue in -keep-08
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2010 19:59:31 -0000

I believe there is a serious problem with the recommendations in the Security Considerations section in keep-08
where it discusses having downstream elements change the keep parameter.

Consider this scenario. A user agent implementing this specification sends a request that goes through two
proxies before it arrives at its destination. The first proxy does not know about this specification. The second
proxy does, and chooses to attempt to maliciously affect the relationship between UA1 and P1 as suggested
in these security considerations.

View the following flow in a fixed-width font:

UA1                  P1               P2    UA2
 |                   |                |      | 
 | INVITE            |                |      |
 | Via: UA;keep      | INVITE         |      |
 |------------------>| Via: P1        |      | 
 |                   | Via: UA;keep   |      | 
 |                   |--------------->|      |
 |                   |                |----->| 
 |                   |                | 200  |
 |                   | 200            |<-----|
 |                   | Via: P1        |      |
 | 200               | Via: UA;keep=1 |      |
 | Via: UA;keep=1    |<---------------|      |
 |<------------------|                |      | 
 |                   |                |      | 

Since P1 doesn't support this specification, it does not know to look at "it's" Via to see if some downstream
element has modified what it would have put in the keep parameter value - the recommendation in the current
draft does not mitigate this attack at all. If the hop between UA1 and P1 is UDP, this may result in STUN being
send towards P1's SIP listening port with P1 not expecting (or being able to deal with) it.

This is a general problem with attempting to use Via parameters to indicate support for extensions. A similar
problem exists for ;rport, and for ;lr. However, if a downstream element abused those parameters, signaling
is guaranteed to fail. This proposed parameter has a different property - this abuse may only result in extra traffic
for someone else.

I don't think this document is the right place to solve the general problem, but this discussion needs to be
rewritten to be clearer about the problem and the lack of any current way to mitigate it.