Re: [secdir] secdir review of draft-ietf-sipcore-invfix-01

Robert Sparks <rjsparks@nostrum.com> Wed, 23 June 2010 21:34 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12963A6867; Wed, 23 Jun 2010 14:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.133
X-Spam-Level:
X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cutFwh170K02; Wed, 23 Jun 2010 14:34:39 -0700 (PDT)
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 EE4423A69FD; Wed, 23 Jun 2010 14:34:35 -0700 (PDT)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5NLYUo9001834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Jun 2010 16:34:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50AC62950@xmb-sjc-225.amer.cisco.com>
Date: Wed, 23 Jun 2010 16:34:29 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <0F999805-9A9F-477D-88DD-EB2F7A6AEB1B@nostrum.com>
References: <AC1CFD94F59A264488DC2BEC3E890DE50AC62950@xmb-sjc-225.amer.cisco.com>
To: Joseph Salowey (jsalowey) <jsalowey@cisco.com>
X-Mailer: Apple Mail (2.1081)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: iesg@ietf.org, draft-ietf-sipcore-invfix.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-sipcore-invfix-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2010 21:34:44 -0000

Joseph -

As one of the document editors, I'd like to thank you for your review.

As the document notes, the additional state that is being maintained
is necessary for correct operation, and that state is taken on only when
the server has decided to accept the INVITE request with a 200 OK.  
The techniques you point to would be useful if applied before getting to 
this point, and the concept is called out in the security considerations
section of RFC3261 in section 26.3.2.4. I will suggest adding a pointer
to that section in the security considerations in this document.

Thanks!

RjS

On Jun 21, 2010, at 5:53 PM, Joseph Salowey (jsalowey) wrote:

> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the 
> security area directors.  Document editors and WG chairs should treat 
> these comments just like any other last call comments.
> 
> The document fixes a real problem and seems to address some existing
> security issues, namely the forwarding of stray responses.  This is
> good.  It does introduce more of a possibility of denial of service
> since state must be maintained to track valid responses and this is
> noted in the security considerations as well.  I'm not all that familiar
> with SIP, but there are techniques used in other protocols to avoid
> "flood" type of attacks by delaying committing state until the client
> has successfully processed a server message.   TCP cookies, IKEv2 and
> DTLS have examples of this. This would be something to consider if
> implementations were vulnerable to flood type attacks in deployments.  
> 
> 
> Joe