Subject: [Sidrops] I-D Action: draft-ietf-sidrops-validating-bgp-speaker-00.txt

From: [email-masked]
Date: Thu, 01 Feb 2018 10:49:33 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIDR Operations WG of the IETF.

        Title           : Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers
        Authors         : Thomas King
                          Christoph
                          Daniel Kopp
                          Aristidis Lambrianidis
                          Arnaud Fenioux
	Filename        : draft-ietf-sidrops-validating-bgp-speaker-00.txt
	Pages           : 9
	Date            : 2018-02-01

Abstract:
   This document defines a new BGP transitive extended community, as
   well as its usage, to signal prefix origin validation results from an
   RPKI Origin validating BGP speaker to other BGP 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-validating-bgp-speaker/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sidrops-validating-bgp-speaker-00
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-validating-bgp-speaker-00

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: Aris Lambrianidis <[email-masked]>
Date: Wed, 07 Feb 2018 19:37:24 +0100

Greetings everyone,

Might we again solicit feedback on the draft? It is an evolution of
draft-ietf-sidr-route-server-rpki-light, with the
following *key* changes:

1. It now discusses BGP speakers instead of IXP route servers

Reason: The draft can be applicable to any network operator instead of
just IXPs.

2. It introduces a new EBGP Prefix Origin Validation Extended Community
(instead of re-using the         
BGP Prefix Origin Validation State Extended Community as described in
RFC8097).

Reason: This new community includes the AS number of the validating BGP
speaker in its Global Administrator
field, a crucial piece of information for troubleshooting.

Many thanks to the valuable feedback so far on and off this list for
bringing the draft to its current state.

Kind regards,
Aris

[email-masked] wrote:
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Wed, 7 Feb 2018 19:04:42 +0000

Hi,

I think a much safer mode of operation for BGP speakers is to reject
invalid announcements, rather than "tag with extended bgp community &
propagate".

Merely tagging announcements with some community and hoping the remote
peer will take some action on the community seems a bit silly...

I'd suggest to remove "Simple tagging" and "Prioritizing and Tagging"
from Section 3. And remove "2 - Lookup result = invalid" from Table 1 in
Section 4.

Kind regards,

Job

---

From: Aris Lambrianidis <[email-masked]>
Date: Wed, 14 Feb 2018 23:39:50 +0100

Hi Job,

> invalid announcements, rather than "tag with extended bgp community &
If RPKI adoption and know-how was widespread, I would agree. Sadly, this
is not the
operational reality as I see it. The draft tries to be inclusive in its
options as to
promote RPKI adoption, but as stated in a previous email of mine, this
is just one of its goals.

>From a standardization standpoint (the other goal), offering less
options on how operators deploy the
validating bgp speaker means less probability of widespread adoption,
thereby
defeating its purpose.

Furthermore, if we were to go directly with the safer mode of operation,
we would lose operators who are on the fence about RPKI and its
usefulness and
who want to maintain more granular control on what they receive before
pulling the proverbial
killswitch, taking into account what was mentioned in the first paragraph.

If it helps, I see the draft as an analogy to the migration steps taken
with any new technology, i.e. installing
firewalls or proxies in one's network. Typically they are first being
placed in "bypass/monitoring"
mode, and then they are configured to filter/drop traffic, after
confidence of their operation has been gained.

The draft in no way prohibits, and arguably even encourages, operators
to offer different options for different customers.
Customers who feel confident in the validating BGP speaker can simply
select to reject invalid announcements.

Kind regards,
Aris