[secdir] Secdir last call review of draft-ietf-teas-rsvp-ingress-protection-13

Joseph Salowey <joe@salowey.net> Wed, 28 February 2018 06:57 UTC

Return-Path: <joe@salowey.net>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E72B612DA14; Tue, 27 Feb 2018 22:57:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joseph Salowey <joe@salowey.net>
To: secdir@ietf.org
Cc: iesg@ietf.org, teas@ietf.org, draft-ietf-teas-rsvp-ingress-protection.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.73.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151980106388.5124.1750215397283002470@ietfa.amsl.com>
Date: Tue, 27 Feb 2018 22:57:43 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/awOHHDaBpO0o7pCDoxlHmOOzEWs>
Subject: [secdir] Secdir last call review of draft-ietf-teas-rsvp-ingress-protection-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 28 Feb 2018 06:57:44 -0000

Reviewer: Joseph Salowey
Review result: Ready

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.

In general I felt that the document was a bit difficult to read and the issues
raised in the Genart and RTG reviews should be addressed.

>From a security point of view I believe the document is ready, but I have a
comment below that might improve the document.

I find the security considerations as reference to other documents a bit
unsettling, however, based on my somewhat limited understanding of RSVP it
think it is accurate in this case.  The problem I have with the security
considerations as reference is that most implementors are probably are not
going to follow the links to the other documents to find out what security
wisdom lies therein.   If the document pointed to specific considerations in
other documents that were particularly relevant to this document that would be
an improvement.  I couldn't work my way back through the chain of references to
something specific, but someone with a bit more RSVP domain knowledge may be
able to make some specific recommendations.