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

[Job Snijders <[e-mail]>]

Hi all,

On Tue, Jul 25, 2017 at 04:38:38PM +0200, Aris Lambrianidis wrote:
> We’re working on an updated draft to elaborate further on the valid
> path hiding concerns you raised, as well as describing a new
> transitive extended BGP community attribute, (instead of reusing the
> one described in RFC8097), based on Job Snijders’ offline comments.

I had some more dialogue with Aris off-list, and the following idea came up:

With the current approach as outlined in sidrops-route-server-rpki-light-02 
I find the anonymous attestation "this is a valid route" problematic.
However if hints are provided which ASN made the claim, the idea of
well-known communities to signal observed states is perhaps less
problematic.

What if a "Transitive Four-Octet AS-Specific Extended Community Sub-Type"
is used and (route server) operators put their own ASN in the Global
Administrator field, and an integer signifying the observed state in the
Local Administrator field. 

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x02     | Sub-Type TBD  |      Global Administrator     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   : Global Administrator (cont.)  |        validationstate        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	(validationstate: 0 = "valid", 1 = "not found", 2 = "invalid")

While i am still not entirely sold on the idea of "RPKI Light", this
approach would alleviate some of my concerns:

    - As a transitive type, this community is allowed to cross EBGP
      boundaries without causing controversy;

    - by putting the attesting network's ASN in the Global Administrator
      field, any users of the community will need to explicitly
      configure their routing policy to match on those parameters, and
      we can then reasonably expect them to scrub in the appropiate
      places as well. This is a form of "opt-in".

Furthermore I think the draft's intended status should be adjusted
from "Standards track" to "Informational" (as is customary for most
well-known communities). Half of the "Transitive Four-Octet AS-Specific
Extended Community Sub-Types" space is FCFS anyway, so "Informational"
is sufficient to obtain a codepoint.

Thoughts?

Kind regards,

Job