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