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

["Jakob Heitz (jheitz)" <[e-mail]>]

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.

> -----Original Message-----
> From: Montgomery, Douglas (Fed) [mailto:[e-mail]]
> Sent: Friday, March 03, 2017 11:36 AM
> To: Alvaro Retana (aretana) <[e-mail]>; Jakob Heitz (jheitz) <[e-mail]>; draft-ietf-sidr-origin-
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard
> (draft-ietf-sidr-origin-validation-signaling-11.txt)
> Importance: Low
> 
> 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)"
> <[e-mail] on behalf of [e-mail]> 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)"
> ><[e-mail] on behalf of [e-mail]> 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?
> >
> >    I don't see that condition covered in the draft.
> >    I would say to ignore the extended community.
> >
> >    Thanks,
> >    Jakob.
> >
> >    > -----Original Message-----
> >    > From: sidr [mailto:[e-mail]] On Behalf Of The IESG
> >    > Sent: Wednesday, January 11, 2017 7:25 AM
> >    > To: IETF-Announce <[e-mail]>
> >    > Cc: [e-mail];
> >[e-mail]; [e-mail]; The IESG
> >    > <[e-mail]>; [e-mail]; [e-mail]
> >    > 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
> >    > [e-mail]
> >    > https://www.ietf.org/mailman/listinfo/sidr
> >
> >
> >
> >_______________________________________________
> >sidr mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/sidr