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

[Aris Lambrianidis <[e-mail]>]

Hi,

Two comments:

1. Regarding transitivity of the extended community: This draft
was never meant to replace RPKI. To state the obvious, it is
impossible to do so, as  cryptographic assurance does not
exist for BGP communities.

This basically means that any caveats applicable for known
(and unknown) communities still apply. At its core, it's merely an
informational tag. I would expect it should be up to the administrative
authority to decide whether and how much they:

a) Would trust such a tag (hopefully not at all if they are far
removed from the AS conducting the validation, and marginally,
if at all, if they are directly connected)

b) Would scrub such communities or

c) Would propagate them to its EBGP peers.

As an example, I would certainly not consider it a general good practice
to pass on such a tag to my upstreams, but I could see
a use case in which I, as a single authority, administer
multiple (non-confederated) Autonomous Systems and would like the community
be propagated across these.

2. Personally, I believe including the ASN conducting the Prefix Origin Validation
as a field within the encoding makes sense, for the reasons Job stated.

I’ve already committed a version of the draft in our repository to reflect this
change, but I’ll wait for author consensus before we submit a newer draft to
the IETF repository.

 --Aris


> On 25 Jul 2017, at 20:45, Job Snijders <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops