Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)

From: Randy Bush <[email-masked]>
Date: Fri, 03 Mar 2017 09:32:51 +0900

> What happens if a BGP speaker validates a route in its own RPKI
> database and finds it to be either Valid or Invalid (not NotFound) and
> also receives the extended community that specifies a different
> validation state?
> 
> I don't see that condition covered in the draft.
> I would say to ignore the extended community.

agree

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Fri, 3 Mar 2017 19:35:47 +0000

I am not sure I understand the original question/point and/or Alvaro's
response.

The spec in section 2 says:

“...Similarly on the receiving IBGP speakers, the validation state of an
IBGP route SHOULD be derived directly from the last octet of the extended
community, if present.”

That seems like a suggested receive logic … although it is a SHOULD.  Of
course it is still up to local policy how this validation state effects
the decision process.

I think it would be a mistake to make some change that suggested that the
received validation state on a iBGP update should somehow influence the
computed origin validation state of other received updates.  In particular
influencing the validation state of any locally validated updates.  The
original question seems to suggest that a received INVALID or VALID might
supersede a “NOT_FOUND”. (was that the suggestion?)  Such a situation
represents an RPKI state skew between the two routers (might just be
transitory) but it is impossible to tell if the I/V or the NF represents
the more “up to date” result.  Also having the origin validation results
of a router that is doing OV overwritten by some other router (possibly
synced to a different validating cache) will make debugging OV results
very difficult.

In short, for now, I would not change the spec.  With some operational
experience we might find some use for similar functionality (I wonder if
by NOT_FOUND you meant not validated) but for now, I would not change it.

dougm
— 
Doug Montgomery, Mgr Internet & Scalable Systems Research at  NIST/ITL/ANTD

On 2/23/17, 4:55 PM, "sidr on behalf of Alvaro Retana (aretana)"
<[email-masked] on behalf of [email-masked]> wrote:

>[Took the IESG, ietf-announce and rfc-editor lists off.]
>
>Jakob:
>
>Hi!
>
>This document is already in AUTH48.  I don’t think we need to make any
>changes to the document, but if we do, we need to decide very soon.
>
>The document doesn’t say anything about what should be done with this
>extended community, except to say that “speakers that receive this
>validation state can configure local policies allowing it to influence
>their decision process.”  IOW, there is no expected default processing of
>the validation state.
>
>If the community is received and the router also has validation
>information, then I agree that the extended community is not needed…but I
>think that action is outside the scope of this document.
>
>Thanks!
>
>Alvaro.
>
>
>
>
>On 2/23/17, 4:26 PM, "iesg on behalf of Jakob Heitz (jheitz)"
><[email-masked] on behalf of [email-masked]> wrote:
>
>database
>    and finds it to be either Valid or Invalid (not NotFound) and also
>receives
>    the extended community that specifies a different validation state?
>    
>    Thanks,
>    Jakob.
>    > -----Original Message-----
>    > From: sidr [mailto:[email-masked]] On Behalf Of The IESG
>    > Sent: Wednesday, January 11, 2017 7:25 AM
>    > To: IETF-Announce <[email-masked]>
>    > Cc: [email-masked];
>[email-masked]; [email-masked]; The IESG
>    > <[email-masked]>; [email-masked]; [email-masked]
>    > Subject: [sidr] Protocol Action: 'BGP Prefix Origin Validation
>State Extended Community' to Proposed Standard
>    > (draft-ietf-sidr-origin-validation-signaling-11.txt)
>    > 
>    > The IESG has approved the following document:
>    > - 'BGP Prefix Origin Validation State Extended Community'
>    >   (draft-ietf-sidr-origin-validation-signaling-11.txt) as Proposed
>    > Standard
>    > 
>    > This document is the product of the Secure Inter-Domain Routing
>Working
>    > Group.
>    > 
>    > The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah
>    > Brungard.
>    > 
>    > A URL of this Internet Draft is:
>    > 
>https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signali
>ng/
>    > 
>    > 
>    > 
>    > 
>    > 
>    > Technical Summary
>    > 
>    >    This document defines a new BGP opaque extended community to
>carry
>    >    the origination AS validation state inside an autonomous system.
>    >    IBGP speakers that receive this validation state can configure
>local
>    >    policies allowing it to influence their decision process.
>    > 
>    > Working Group Summary
>    > 
>    >   This document has had consistent interest from the working group.
>    >   Because it defines a new BGP community, it was reviewed by the idr
>    >   working group as well.
>    > 
>    > Document Quality
>    > 
>    >   The document has been implemented by major router vendors.
>    >   It is known to be in use in two large IXPs, AMS-IX and DE-CIX.
>    > 
>    > Personnel
>    > 
>    >   Document Shepherd: Sandra Murphy
>    >   Responsible Area Director: Alvaro Retana
>    > 
>    > _______________________________________________
>    > sidr mailing list
>    > [email-masked]
>    > https://www.ietf.org/mailman/listinfo/sidr
>    
>    
>
>_______________________________________________
>sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 3 Mar 2017 20:24:44 +0000

The case is unlikely, but something we need to write code for.
Without an answer, then the validity will just be set by whichever
was set last. That would make it indeterminate.

The case is for a single route. There is no suggestion of the validity
of one route being used to set validity of another.

A router may be doing local validation, using rpki-rtr protocol.
In additiion, it may receive a route with a validation state in
an extended-community.

The question is what to do if one validation method sasys "invalid"
and the other says "valid".

The situation may arise if the router sending the extended-community
is using a different validation method, not RPKI.

Thanks,
Jakob.

> From: Montgomery, Douglas (Fed) [mailto:[email-masked]]
> Sent: Friday, March 03, 2017 11:36 AM
> To: Alvaro Retana (aretana) <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>; draft-ietf-sidr-origin-
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard
> Importance: Low

---

From: Keyur Patel <[email-masked]>
Date: Fri, 3 Mar 2017 20:43:18 +0000

Jacob,

Apologies for the delayed response. Comments #Keyur

On 2/23/17, 1:26 PM, "Jakob Heitz (jheitz)" <[email-masked]> wrote:

    What happens if a BGP speaker validates a route in its own RPKI database
    and finds it to be either Valid or Invalid (not NotFound) and also receives
    the extended community that specifies a different validation state?
    
#Keyur: That pretty much means that ibgp speakers has out of sync rpki data. This could very well happen if the ibgp speakers have different refresh intervals for polling the rpki data (or some error has occurred that has resulted into a stale state).

#Keyur: I am not sure if we need to add any text? Extended community maps to a policy on a n inbound side. Policy would dictate how you would want to use the community. Implementations could always log any conflicting rpki state they encounter?

Regards,
Keyur

    Thanks,
    Jakob.
    
    > Cc: [email-masked]; [email-masked]; [email-masked]; The IESG
    > Subject: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard
    > This document is the product of the Secure Inter-Domain Routing Working
    > Group.
    > 
    > https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/
    > 
    > 
    > 
    > 
    > 
    > Technical Summary
    > 
    >    This document defines a new BGP opaque extended community to carry
    >    IBGP speakers that receive this validation state can configure local

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 3 Mar 2017 21:15:07 +0000

I assume that the ext-comm passes policy.

Thanks,
Jakob.

> From: Keyur Patel [mailto:[email-masked]]
> Sent: Friday, March 03, 2017 12:43 PM
> To: Jakob Heitz (jheitz) <[email-masked]>; The IESG <[email-masked]>; IETF-Announce <ietf-
> [email-masked]>
> #Keyur: That pretty much means that ibgp speakers has out of sync rpki data. This could very well happen if the ibgp
> speakers have different refresh intervals for polling the rpki data (or some error has occurred that has resulted
> into a stale state).
> 
> #Keyur: I am not sure if we need to add any text? Extended community maps to a policy on a n inbound side. Policy
> would dictate how you would want to use the community. Implementations could always log any conflicting rpki state
> they encounter?
> 
> Regards,
> Keyur
> 
>     Thanks,
>     Jakob.
>

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Fri, 3 Mar 2017 21:56:17 +0000

>of one route being used to set validity of another.

By single route, do you mean an update from a specific iBGP peer?  Or do
you mean updates from two or more iBGP peers?

>In additiion, it may receive a route with a validation state in

In this case are you saying the router is doing origin validation on iBGP
updates, even though they contain the extended-community?

If so, I would suggest one keep/use the locally computed validation state,
not the signaled state.

>is using a different validation method, not RPKI.

It can also happen if all routers are doing RPKI, but there is transient
RPKI state skew between multiple validating caches, local SLURM policies,
etc.

>> To: Alvaro Retana (aretana) <[email-masked]>; Jakob Heitz (jheitz)
>><[email-masked]>; draft-ietf-sidr-origin-
>> Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 3 Mar 2017 22:15:54 +0000

Thanks. This is the part I was looking for:

> I would suggest one keep/use the locally computed validation state,
> not the signaled state.

Jakob.

> Sent: Friday, March 03, 2017 1:56 PM
> To: Jakob Heitz (jheitz) <[email-masked]>; Alvaro Retana (aretana) <[email-masked]>; draft-ietf-sidr-origin-

---

From: Randy Bush <[email-masked]>
Date: Sat, 04 Mar 2017 09:13:22 +0900

i am very confused.  what is the actual problem here?

if the community arrives at a router that has computed a validation
state from local data, the community's state must be ignored.

does the spec need to be clarified in this aspect?  if so, text would be
helpful.

randy

---

From: Chris Morrow <[email-masked]>
Date: Fri, 03 Mar 2017 22:59:20 -0500

At Sat, 04 Mar 2017 09:13:22 +0900,
> does the spec need to be clarified in this aspect?  if so, text would be

It sounds like implementers are unsure if the 3rd back sentence is
correct/intended. How about:

Section 2, 3rd paragraph:

  "Similarly on the receiving IBGP speakers, the validation
   state of an IBGP route SHOULD be derived directly from the last octet
   of the extended community, if present."

to:
 "Similarly on the receiving IBGP speakers, the validation state of
  an IBGP route SHOULD be derived directly from the last octet of the
  extended community, if present. A receiving router should use
  locally achieved validation state before trusting an IBGP neighbors
  state information."

-chris

---

From: Randy Bush <[email-masked]>
Date: Sat, 04 Mar 2017 13:05:11 +0900

>   locally achieved validation state before trusting an IBGP neighbors

sure.  or, tersified, 

  "Similarly, a receiving IBGP speaker, in the absence of validation
   state set based on local data, SHOULD derive a validations state from
   the last octet of the extended community, if present."

randy

---

From: Chris Morrow <[email-masked]>
Date: Fri, 03 Mar 2017 23:22:55 -0500

At Sat, 04 Mar 2017 13:05:11 +0900,
>    the last octet of the extended community, if present."

great!

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 4 Mar 2017 04:28:46 +0000

Both are a bit mushy.
The ext-comm may come from an ebgp neighbor.
I want to make sure that the not-found state is not interpreted as
a locally achieved validation state. If the local state is not-found,
then the received ext-comm should count.

  "Similarly on the receiving IBGP speakers, the validation state of
  an IBGP route SHOULD be derived directly from the last octet of the
  extended community, if present. If a receiving router is performing
  RPKI validation locally and has determined a state other than
  not-found, then the state determined by the extended community
  SHOULD NOT be used."

Thanks,
Jakob.

> From: Randy Bush [mailto:[email-masked]]
> Sent: Friday, March 03, 2017 8:05 PM
> To: Chris Morrow <[email-masked]>
> Cc: Montgomery, Douglas (Fed) <[email-masked]>; Alvaro Retana (aretana) <[email-masked]>; Jakob Heitz (jheitz)
> <[email-masked]>; [email-masked]; [email-masked]; [email-masked];
> [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Sat, 04 Mar 2017 13:36:05 +0900

> The ext-comm may come from an ebgp neighbor.

ok.  saves a character.  my kind of change :)

  "Similarly, a receiving BGP speaker, in the absence of validation
   state set based on local data, SHOULD derive a validations state from
   the last octet of the extended community, if present."

randy

---

From: Chris Morrow <[email-masked]>
Date: Fri, 03 Mar 2017 23:37:31 -0500

At Sat, 04 Mar 2017 13:36:05 +0900,
> > The ext-comm may come from an ebgp neighbor.

ebgp neighbor? the text talks about ibgp, and about explicitly ignoring ebgp senders of this community (by default).

right?

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 4 Mar 2017 04:40:03 +0000

However it SHOULD be possible to
   configure an implementation to send or accept the community when
   warranted.  An example of a case where the community would reasonably
   be received from, or sent to, an EBGP peer is when two adjacent ASes
   are under control of the same administration.  A second example is
   documented in [I-D.ietf-sidr-route-server-rpki-light].

Thanks,
Jakob.

> From: Chris Morrow [mailto:[email-masked]]
> Sent: Friday, March 03, 2017 8:38 PM
> To: Randy Bush <[email-masked]>
> Cc: Jakob Heitz (jheitz) <[email-masked]>; Chris Morrow <[email-masked]>; Montgomery, Douglas (Fed)
> <[email-masked]>; Alvaro Retana (aretana) <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Sat, 04 Mar 2017 13:42:15 +0900

> ebgp neighbor? the text talks about ibgp, and about explicitly
> ignoring ebgp senders of this community (by default).

if it does not say MUST NOT accept from ebgp, the jakob has to have
code.  imiho, it sould say MUST NOT accept from engp.

randy

---

From: Keyur Patel <[email-masked]>
Date: Sat, 4 Mar 2017 05:18:16 +0000

Jacob,

Ebgp Peers are out of scope. Imho, implementations are free to implement receipt and processing of a community from a ebgp peer as a knob. The standard doesn't have to accommodate knobs.

Regards,
Keyur

Sent from my iPhone

> On Mar 3, 2017, at 8:40 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 4 Mar 2017 05:23:53 +0000

I pasted from the draft.

Thanks,
Jakob.

> On Mar 3, 2017, at 9:18 PM, Keyur Patel <[email-masked]> wrote:
> 
> Jacob,
>