Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-01.txt
Job Snijders <job@ntt.net> Mon, 16 January 2017 10:50 UTC
Return-Path: <job@ntt.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D5B129452 for <sidrops@ietfa.amsl.com>; Mon, 16 Jan 2017 02:50:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.134
X-Spam-Level:
X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 iCMzgvrlXTwS for <sidrops@ietfa.amsl.com>; Mon, 16 Jan 2017 02:50:27 -0800 (PST)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 819EC129447 for <sidrops@ietf.org>; Mon, 16 Jan 2017 02:50:27 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1cT4rq-000BYB-6C (job@us.ntt.net); Mon, 16 Jan 2017 10:50:27 +0000
Date: Mon, 16 Jan 2017 11:50:21 +0100
From: Job Snijders <job@ntt.net>
To: sidrops@ietf.org
Message-ID: <20170116105021.GQ1055@Vurt.local>
References: <148456125062.22532.12814474427952712942.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <148456125062.22532.12814474427952712942.idtracker@ietfa.amsl.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/6b6wPJu9eyPIHz_9O4LBs7Pj2ek>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-01.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jan 2017 10:50:29 -0000
Hi, This version of the draft does not clarify why there is a difference between a Route Server signalling prefix origin validation results through the communities defined in draft-ietf-sidr-origin-validation-signaling, and any other ASN signalling those communities via an eBGP session. Right now the two documents appear in relation to each other as following: - draft-ietf-sidr-origin-validation-signaling-10.txt "define 3 communities" - draft-ietf-sidrops-route-server-rpki-light "you can attach those 3 communities to a prefix and announce them" So what is the point? Either a generalised mechanism should be defined in which the pro's and con's of outsourcing one's routing security are explicitly highlighted and applies to all networks, or a justification should be provided why a Route Server is different from any other ASN in this specific context. A small note: the draft states: "The introduction of a mechanisms described in this document does not pose a new class of attack vectors to the relationship between route- servers and peers." - however this is not true from an internal consistency point of view. Earlier on in the section this is written: "Therefore, a route-server could be misused to spread malicious prefix origin validation results." .. so which is it? For completeness sake, can the authors (or someone) provide a configuration example on any platform which implements the recommendations mentioned in section 3.4 "Error Handling at Peers"? I'd also like to note that this version still promotes an insecure mode of operation. Kind regards, Job On Mon, Jan 16, 2017 at 02:07:30AM -0800, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIDR Operations of the IETF. > > Title : Signaling Prefix Origin Validation Results from a Route-Server to Peers > Authors : Thomas King > Daniel Kopp > Aristidis Lambrianidis > Arnaud Fenioux > Filename : draft-ietf-sidrops-route-server-rpki-light-01.txt > Pages : 6 > Date : 2017-01-16 > > Abstract: > This document defines the usage of the BGP Prefix Origin Validation > State Extended Community [I-D.ietf-sidr-origin-validation-signaling] > to signal prefix origin validation results from a route-server to its > peers. Upon reception of prefix origin validation results peers can > use this information in their local routing decision process. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-light/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-route-server-rpki-light-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops
- [Sidrops] I-D Action: draft-ietf-sidrops-route-se… internet-drafts
- Re: [Sidrops] I-D Action: draft-ietf-sidrops-rout… Job Snijders