[secdir] Secdir last call review of draft-ietf-sidrops-ov-clarify-03

Yoav Nir <ynir.ietf@gmail.com> Sat, 04 August 2018 20:33 UTC

Return-Path: <ynir.ietf@gmail.com>
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 410D3130DE9; Sat, 4 Aug 2018 13:33:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yoav Nir <ynir.ietf@gmail.com>
To: secdir@ietf.org
Cc: draft-ietf-sidrops-ov-clarify.all@ietf.org, sidrops@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153341478021.31715.18305969749704687082@ietfa.amsl.com>
Date: Sat, 04 Aug 2018 13:33:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/HvdEOfvfpreD_XWKoKHr1EIhZbQ>
Subject: [secdir] Secdir last call review of draft-ietf-sidrops-ov-clarify-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
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: Sat, 04 Aug 2018 20:33:00 -0000

Reviewer: Yoav Nir
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.

The document clarifies two things about RFC 6811:

That all routes MUST be marked as Valid, Invalid, or NotFound unless policy
specifically says not to do so. The original text in RFC 6811 said SHOULD
(perform a lookup...) and MAY (provide configuration options...), so this
interpretation seems to be already strongly implied by 6811.

That policy (such as rejecting invalid routes) MUST NOT be applied unless the
operator specifically configured it. RFC 6811 already says, "An implementation
MUST NOT exclude a route from the Adj-RIB-In or from consideration in the
decision process as a side effect of its validation state, unless explicitly
configured to do so." so I believe this is already stated in RFC 6811. Still,
the text says that some implementers got it wrong.

So I think the claim in the security considerations section, that this document
does not introduce any security considerations beyond those of 6811 is
reasonable. The fact that the security policy suggested by RFC 6811 MUST NOT be
turned on by default may have been pointed out more emphatically, but this
perhaps should have to be done in 6811.