Re: [Idr] Roman Danyliw's No Objection on draft-ietf-idr-eag-distribution-16: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 19 May 2021 04:12 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA9E3A1CF7; Tue, 18 May 2021 21:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njxTqZQrzWc6; Tue, 18 May 2021 21:12:21 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BB23A1B42; Tue, 18 May 2021 21:12:21 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14J4CCAJ021099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 May 2021 00:12:16 -0400
Date: Tue, 18 May 2021 21:12:11 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, Roman Danyliw <rdd@cert.org>, draft-ietf-idr-eag-distribution@ietf.org, idr@ietf.org, aretana.ietf@gmail.com, Susan Hares <shares@ndzh.com>, idr-chairs@ietf.org
Message-ID: <20210519041211.GI32395@kduck.mit.edu>
References: <162134343909.18873.6150461240123862844@ietfa.amsl.com> <3d06050a-4e2d-44c5-873a-0dc3518655e6@Spark>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3d06050a-4e2d-44c5-873a-0dc3518655e6@Spark>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/iDRkzzAa_Yb9wsahi9ZXwsWOlwU>
Subject: Re: [Idr] Roman Danyliw's No Objection on draft-ietf-idr-eag-distribution-16: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2021 04:12:27 -0000

Hi Jeff,

I'm not Roman, but I would have made the same comment.

I don't think that this is quite a question of "just" adding more
references -- the -16 currently says that there is some kind of
"required security [mechanisms?]" from the IGP, and that RFC 7308 specifies
how to achieve that level of required security.  While RFC 7308 clearly is
not a good reference for that, the question as to what the "required
security [mechanisms?]" is/are remains unanswered.  Once we know the answer
to that, we can give better guidance about what references to use and how
to write the text using those references.

Thanks,

Ben

On Tue, May 18, 2021 at 10:38:16PM -0500, Jeff Tantsura wrote:
> Hi Roman,
> 
> Thanks for your review.
> 
> I see your point, practically, this draft uses  BGP-LS (RFC7752) to transport IGP data, and 7752 talks in details about security considerations.
> The security section of RFC7308 is indeed quite short.
> Would adding references to security sections of  OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305) work for you?
> 
> Thanks!
> 
> Cheers,
> Jeff
> On May 18, 2021, 8:10 AM -0500, Roman Danyliw via Datatracker <noreply@ietf.org>rg>, wrote:
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-idr-eag-distribution-16: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-idr-eag-distribution/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Per Section 4 (Security Considerations),
> >
> > It is assumed that the IGP instances originating this TLV
> > will support all the required security (as described in [RFC7308]) in
> > order to prevent any security issues when propagating the TLVs into
> > BGP-LS.
> >
> > The Security Considerations (Section 3) of RFC7308 reads "This extension adds
> > no new security considerations." What guidance is this sentence providing?
> >
> >
> >