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

["Montgomery, Douglas (Fed)" <[e-mail]>]

On 3/3/17, 3:24 PM, "Jakob Heitz (jheitz)" <[e-mail]> wrote:

>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.

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

>
>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.

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.

>
>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.

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.


>
>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-signa
>>>li
>> >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
>