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

From: Aris Lambrianidis <[email-masked]>
Date: Mon, 17 Jul 2017 15:28:28 +0200

Hello all,

As a quick note, Daniel and I are in Prague, at IETF99. Daniel will be here until Tuesday afternoon and I’ll be here
for the entire week, should you have any concerns, comments, or questions. We’re looking into moving things forward
(read: go for WG Last Call), so we’d appreciate any feedback, in person or by email.

--Aris

> On 11 Apr 2017, at 18:15, Thomas King <[email-masked]> wrote:
> 
> Hi all,
> 
> we have worked on the feedback we received through many channels (e.g. this mailing list):
> - Clarification of the “Security Considerations” section. Please let us know if you think a security issue is not tackled.
> - The feedback told us that different modes of operation for how “invalid” and “not found” routes should be handled needs to be addressed. For this, section “BGP Prefix Origin Validation State Utilized at Route-Servers” was added.
> - House-Keeping (e.g. update references, fix typos)
> 
> Best regards,
> Thomas
> 
> 
> On 11/04/2017, 18:14, "Sidrops on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> 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-02.txt
>    	Pages           : 7
>    	Date            : 2017-04-11
> 
>    Abstract:
>       This document defines the usage of the BGP Prefix Origin Validation
>       State Extended Community [RFC8097] 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 are also htmlized versions available at:
>    https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-02
>    https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-route-server-rpki-light-02
> 
>    A diff from the previous version is available at:
>    https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-route-server-rpki-light-02
> 
> 
>    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
>    [email-masked]
>    https://www.ietf.org/mailman/listinfo/sidrops
> 
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 21 Jul 2017 14:15:39 +0100

Aris,

the concerns I brought up about this draft on jan 13 / jan 14 have not
been addressed in -01 or -02.  The concerns were basically: this is not
how to solve the problem of making things easier for route server
clients + the reasons why.

Nick

Aris Lambrianidis wrote:
> Hello all,
> 
> As a quick note, Daniel and I are in Prague, at IETF99. Daniel will be
> here until Tuesday afternoon and I’ll be here
> for the entire week, should you have any concerns, comments, or
> questions. We’re looking into moving things forward
>> On 11 Apr 2017, at 18:15, Thomas King <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>
>> - Clarification of the “Security Considerations” section. Please let
>> us know if you think a security issue is not tackled.
>> - The feedback told us that different modes of operation for how
>> “invalid” and “not found” routes should be handled needs to be
>> addressed. For this, section “BGP Prefix Origin Validation State
>> Utilized at Route-Servers” was added.
>> On 11/04/2017, 18:14, "Sidrops on behalf of [email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]> on behalf of
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>    until the htmlized version and diff are available at tools.ietf.org
>> <http://tools.ietf.org>.
>>
>>    [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Aris Lambrianidis <[email-masked]>
Date: Tue, 25 Jul 2017 16:38:38 +0200

Hi Nick,

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.

--Aris

> On 21 Jul 2017, at 15:15, Nick Hilliard <[email-masked]> wrote:
> 
> Aris,
>

---

From: Job Snijders <[email-masked]>
Date: Tue, 25 Jul 2017 17:26:40 +0200

Hi,

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 elaborated that using a non-transitive extended community to cross
EBGP boundaries (in my opinion) is a mis-use of the community transivity
type. I know of a number of BGP implementations which will not send or
accept non-transitive extended communities across EBGP borders.

I am not sure whether a transitive extended community is the way to go
either. A transitive extended community will allow an adversary to
tunnel through networks which don't recognize the semantics of the "BGP
Prefix Origin Validation State Transitive Extended Community" and
possibly negatively impact such networks. This is the trouble with
communities: the granularity available to limit scope and distributino
is very coarse.

I'm not sure there is a good solution here. Any adversy will tag the
malicious announcement as "this is perfectly valid" and hope the 'valid'
community helps mitigate 'rpki light' barriers.

Kind regards,

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 25 Jul 2017 17:27:01 +0000

You accept the community only from those you trust. Internal or external.
Fpr example, if you know that the neighbor is performing validation to your standard.
There is an approximate correlation between trust boundary and AS boundary.
If you trust someone in another AS, then they should be able to send you the commmunity.

Thanks,
Jakob.

> -----Original Message-----
> From: Sidrops [mailto:[email-masked]] On Behalf Of Job Snijders
> Sent: Tuesday, July 25, 2017 8:27 AM
> To: Aris Lambrianidis <[email-masked]>
> Cc: [email-masked]; [email-masked]; Nick Hilliard <[email-masked]>
> Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt
> 
> Hi,
>

---

From: Job Snijders <[email-masked]>
Date: Tue, 25 Jul 2017 19:35:16 +0200

> You accept the community only from those you trust. Internal or external.

A challenge with any new transitive (extended) well-known community is
that until the thing is standardised, people don't know what to filter
and chances are the thing can just pass through anything. There even are
BGP implementations in which you cannot delete unknown extended
communities, so you'd have to wait until you receive a software update
before you can scrub those specific new types.

I don't encourage blanket community scrubbing either. So we have to be
careful when introducing new codepoints associated with specific
semantics.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Tue, 25 Jul 2017 20:45:28 +0200

Hi all,

> 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

---

From: Aris Lambrianidis <[email-masked]>
Date: Tue, 25 Jul 2017 21:15:53 +0200

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 <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Job Snijders <[email-masked]>
Date: Tue, 25 Jul 2017 19:38:17 +0000

On Tue, 25 Jul 2017 at 21:15, Aris Lambrianidis <
[email-masked]> wrote:

> comments:

Perhaps the title of the document can be updated to reflect the recent
changes. How about the following as title: "Signalling BGP Prefix Origin
Validation States with Transitive Extended Communities".

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Jul 2017 10:23:44 +0900

> Validation States with Transitive Extended Communities".

how about "Outsourcing Security Using Transitive Extended Communities?"

randy