[secdir] Secdir review of draft-ietf-martini-gin-10.txt

Radia Perlman <radiaperlman@gmail.com> Wed, 17 November 2010 05:15 UTC

Return-Path: <radiaperlman@gmail.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 AF7593A680C; Tue, 16 Nov 2010 21:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 BrUbrSpIa4em; Tue, 16 Nov 2010 21:15:56 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AE7323A67E4; Tue, 16 Nov 2010 21:15:56 -0800 (PST)
Received: by iwn40 with SMTP id 40so1757202iwn.31 for <multiple recipients>; Tue, 16 Nov 2010 21:16:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=UZoaLeL8o/tbO1vWGOmA+P2aEtOHgCRw5W4H+gPBpJQ=; b=Kzi5dkSh9AXuILFoxr3q3fmHb+VQt9SQmG2A9J+3oYKF9P9qdJSHTKziEjUWEfPa3H IOJ1Y/UP4Gj1fHY+CThHGD4VS1cCuMVHV/b34oWWqLB6axp60U1Ql6GOOACzvcnKlyks /m2WpnxdCacn+uOXKJFK3tQ5IdeSgbKLRJBns=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=N8nHOiMdhhlP+7bGEPFSJHPWBpMG/fBE7ZZReL0cvUmZp4M+UfG3wxeG3vcQBpIGZ+ QK9JRTtSYGt8ataxpzJLyNvrokNLIc/As/qlYFh+RwQol/CQmPlDbHD8T9XSmLRgaZ4D 4GMTF9VFaDmhYSHqZENraWSs8ZZzspi3ud490=
MIME-Version: 1.0
Received: by 10.231.17.9 with SMTP id q9mr6489048iba.109.1289971001020; Tue, 16 Nov 2010 21:16:41 -0800 (PST)
Received: by 10.42.6.66 with HTTP; Tue, 16 Nov 2010 21:16:41 -0800 (PST)
Date: Tue, 16 Nov 2010 21:16:41 -0800
Message-ID: <AANLkTikZva3c=D0tRKg-g3QsCoB-PpcSDUzsmYfJCqrU@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-martini-gin.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [secdir] Secdir review of draft-ietf-martini-gin-10.txt
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, 17 Nov 2010 05:15:57 -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.

This draft defines an extension to the SIP protocol to enable a more
efficient encoding in the case where multiple phone numbers (those
under the control of a SIP-PBX) can roam together. Backwards and
forwards compatibility requirements make this change more complex than
one might expect.

There are no important security considerations for this document other
than the amplification of some DoS attacks, and much of the
information in the Security Considerations section is actually about
requirements for protocol correctness. I would assume the rest
duplicates information from the SIP specification, though I haven't
checked. The bottom line is that I believe the document is just fine
as it is.

I found two minor typos:

1) Page 3 para 2 line 3: "users" -> "user's"

2) The indented text at the end of section 3  was copied from RFC4475,
but in the copying some leading spaces on some of the lines were lost.
Since the purpose of this text is to illustrate how embedded spaces in
actual data will be represented in the body of this RFC, losing those
spaces negates the value of the section.