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

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

I just uploaded the new version of the document including modifications
Made in the following areas.

I had discussions around extended community, eBGP, and RFC4360 including the 
last discussion, Nick has brought to the list. 

Today we modified the draft text and uploaded the newest version. The new version 
does address the issues that were raised during the WLC. Below I try to explain 
a bit the changes and the motivation. 

Of course the regular diff version does the same job.
https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-04


Thanks to all for the discussion and input,
Oliver


Modification 1:
=================
This addresses the issue with RFC4360 and eBGP

Original Text:
   ...
   If the router supports the extension as defined in this document, it 
   SHOULD attach the BGPsec path validation state extended community to 
   BGPsec UPDATE messages sent to BGP peers by mapping the locally 
   computed validation state into the last octet of the extended community.  
   This SHOULD be done automatically for iBGP peers and configurable for 
   eBGP peers (see below).

The last Sentence:
  This SHOULD be done automatically for iBGP peers and
   configurable for eBGP peers (see below).

Is replaced with:
   Operational behavior is governed by Section 6 of [RFC4360].


Modification 2:
=================
This modification addresses Nicks comment regarding the absence of the 
ext comm attribute and what that meant regarding the validation state 
of the UPDATE 

 Original Text:
   In the absence of the extended community, the receiving BGPsec enabled 
   router MUST NOT make any assumption about the validation sate of the 
   UPDATE.

 We added the word "peer's" in front of validation:
   In the absence of the extended community, the receiving BGPsec enabled 
   router MUST NOT make any assumption about the peer's validation state 
   of the UPDATE.


Modification 3:
=================
This addresses Nicks comment regarding the local validation vs. received 
validation. We added the following sentence to the paragraph of Modification 2

Added sentence:
   A locally computed validation state for an UPDATE takes precedence over
   the received validation state.


Modification 4:
=================
This modification removed the mention of eBGP and other handlings of the 
ext com. It is generally handled in RFC4360. We also addressed case #3 of Nick
where a non-BGPsec speaker is involved.

Original Text: 
   By default, routers SHOULD enable use of this community on all iBGP sessions 
   and routers SHOULD disable the use of this community on all eBGP sessions.
   Implementations MUST NOT send more than one instance of the origin validation 
   state extended community and MUST drop (without processing) the BGPsec path 
   validation state extended community if received over an External BGP (eBGP) 
   peering session that has not be explicitly configured to enable processing.

New Text:
  By default, routers SHOULD enable use of this community 
  on all iBGP sessions.  Implementations MUST NOT send more than one instance 
  of the BGPsec validation state extended community. Implementations MUST NOT 
  send the extended community if not in a BGPsec UPDATE. 

  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.






Oliver
-----------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology

On 9/21/20, 5:51 PM, "Borchert, Oliver (Fed)" <[e-mail]> wrote:

    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:

        Keyur Patel wrote on 10/09/2020 18:27:
        > The wg chairs extended the call for a week in hopes that we would have a 
        > consensus. Seems like more discussion is needed and so we plan extend 
        > the call for 1 more week. TheWGLCwill now end on September 17, 2020

        this comment is coming a bit late in the day, but I think it would be an 
        idea to clarify the behaviour of the receiving bgp side a little better.

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

        The draft intends that the bgp receiver treats routes with this extcomm 
        as if they were locally validated by bgpsec.  The simplified state 
        outcome is:

        1. the receiving bgp implementation has bgpsec enabled, and has computed 
        a local validation result for the incoming prefix

        2. the receiving bgp implementation supports bgpsec, but has not 
        computed a local validation result for the incoming prefix

        3. the receiving bgp implementation does not support bgpsec.

        At the moment, the text deals with case #2.  Probably what you want to 
        do here is state that local validation takes preference over the 
        community value.

        Here's some suggested text as a replacement for the paragraph above, 
        which deals with #1 and #2:

        >    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.  If a locally computed BGPsec
        >    validation result is available, then the received BGPsec path validation
        >    state MUST be ignored.
        I'm not sure what you intend with state #3. The choices here are: SHOULD 
        implement alternative policy handling mechanism, SHOULD NOT implement 
        alternative policy handling mechanism, or no advice.

    [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. The community value can be used until local validation
    [ob] is performed. The community attribute serves two purposes. Signaling 
    [ob] the validation state within the boundaries of RFC4360 to (1) allow using
    [ob] a validation state until the router can perform the validation and (2) for 
    [ob] operators to have a tool for diagnosis.

    [ob] I am not really concerned with case #3 because even without the community,
    [ob] operators can create an ext. comm. to signal the validation state to non 
    [ob] BGPsec speakers. 

        Some of this behaviour could be synthesised using normal policy hooks in 
        the bgp stack's configuration grammar, but that would need coding and 
        could be messy if there were ever future plans to support bgpsec because 
        then there would be two frameworks, probably incompatible with each 
        other.  It would certainly be easier for implementers to state that the 
        draft is not intended for bgp stacks which don't already implement 
        bgpsec.  Do the authors have any thoughts on this one?

    [ob] I believe that this community string serves multiple purposes as explained 
    [ob] above and if someone really wants to use community strings to send a 
    [ob] BGPsec validation state to a non BGPsec speaker, they can do so already by
    [ob] hand crafting their own community. Again as it was mentioned during some 
    [ob] email exchange on the list some time ago, the absence of the ext. com. does 
    [ob] not prevent operators of sending validation results. 

        Nick



    Oliver