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

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Mon, 21 June 2010 22:53 UTC

Return-Path: <jsalowey@cisco.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 50CB03A6828; Mon, 21 Jun 2010 15:53:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.443
X-Spam-Level:
X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 OZCH1RQhYzZk; Mon, 21 Jun 2010 15:52:59 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9EA953A67C2; Mon, 21 Jun 2010 15:52:59 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAO+JH0yrR7Ht/2dsb2JhbACfCHGoSJpHhRsEg1Q
X-IronPort-AV: E=Sophos;i="4.53,456,1272844800"; d="scan'208";a="547962288"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 21 Jun 2010 22:53:06 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5LMr6OR001219; Mon, 21 Jun 2010 22:53:07 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Jun 2010 15:53:06 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 21 Jun 2010 15:53:05 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50AC62950@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: secdir review of draft-ietf-sipcore-invfix-01
Thread-Index: AcsRlILLTFp2G4ILQgacbrDPkC9RMg==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: <secdir@ietf.org>, <iesg@ietf.org>, <draft-ietf-sipcore-invfix.all@tools.ietf.org>
X-OriginalArrivalTime: 21 Jun 2010 22:53:06.0501 (UTC) FILETIME=[833FA750:01CB1194]
Subject: [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: Mon, 21 Jun 2010 22:53:00 -0000

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