Subject: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-01.txt

From: [email-masked]
Date: Mon, 16 Jan 2017 02:07:30 -0800

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/

---

From: Job Snijders <[email-masked]>
Date: Mon, 16 Jan 2017 11:50:21 +0100

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, [email-masked] wrote:
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops