Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020

["Borchert, Oliver (Fed)" <[e-mail]>]

Hi Nick,

I'll go inline again, I'll post an update later today,

Oliver


-----------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Office) +1.301.975.4856
(GVoice) +1.240.668.4117
 

On 9/25/20, 8:07 AM, "Nick Hilliard" <[e-mail]> wrote:

    Borchert, Oliver (Fed) wrote on 21/09/2020 22:51:
    > Hi Nick,
    > Please see inline, I added an [ob] in front of my answers.
    > 
    > On 9/21/20, 4:43 PM, "Sidrops on behalf of Nick Hilliard" <[e-mail] on behalf of [e-mail]> wrote:
    >      >    A receiving BGPsec enabled router SHOULD use the received BGPsec path
    >      >    validation state in situations where a locally computed BGPsec
    >      >    validation result is not currently available.  In the absence of the
    >      >    extended community, the receiving BGPsec enabled router MUST NOT make
    >      >    any assumption about the validation sate of the UPDATE.
    > 
    >      The second sentence is a no-op, so it would probably be better to remove it.
    > 
    > [ob] We added that exact wording because during 108, concerns were voiced that
    > [ob] implementations could interpret the absence of the community string as a
    > [ob] particular validation result. To prevent this from happening this addition
    > [ob] was specifically requested.

    right, noted.  I missed the discussion about this in the ietf 108 
    sidrops session.

    > [ob] RFC 8205 clearly states that a router can differ local validation. A good
    > [ob] reason for that could be a temporary resource shortage. In both cases #1 and
    > [ob] #2, I would assume that the implementation follows RFC 8205.
    > 
    > [ob] My understanding was always that local validation takes precedence over
    > [ob] the community value.

    Ben Maddison brought up implementation differences at the ietf108 
    session. You're right that it's probably obvious to anyone on the 
    SIDROPS WG that native BGPsec evaluation should take precedence, but 
    developers or other people reading the specs may make different 
    decisions because they're going to approach the document from a 
    different point of view.  It would be clearer to make this explicit, 
    e.g. to add a single sentence in the Deployment Considerations section 
    to say:

    "If the received validation state of a route differs from a BGPsec 
    validation state locally computed according to [RFC8205], then the 
    locally computed BGPsec validation state MUST be used and the received 
    validation state MUST be ignored".

[ob]
[ob] Sounds good, I'll add that to the end of the "deployment consideration"
[ob]

    On a separate thing, getting back to ebgp stuff, the Deployment 
    Considerations section says:

    >    Furthermore, one can envision that the operator of a BGPsec router
    >    decides to defer local BGPsec validation when a validation state
    >    value is learned via iBGP or a trusted eBGP peer.

    This needs to be reworded because there is no concept of "trusted eBGP" 
    in rfc4360.  Maybe reword as "... when a validation state value is 
    learned via BGP", and just revert to the default behaviour from 4360?

[ob]
[ob] Agreed. It now will read:
[ob]
[ob]  Furthermore, one can envision that the operator of a BGPsec router decides 
[ob]  to defer local BGPsec validation when a validation state value is learned 
[pb]  via BGP.
[ob]

    also nit:

    >    Implementations MUST drop (without processing) the BGPsec path
    >    validation state extended community if received over a peering
    >    session where either the usage is not enabled or it is not part of a
    >    BGPsec UPDATE.

    s/peering session/BGP session/

[ob]
[ob] Agreed.
[ob]

    Nick