On Wed, Aug 17, 2016 at 12:26:32PM +0000, Sriram, Kotikalapudi (Fed) wrote: >o Software MUST mark any routes from an eBGP peer as 'invalid' in > the Adj-RIB-In, if no explicit policy was configured. > >This bullet says “explicit” policy. The next bullet does not say “explicit”. >What is the definition of “explicit policy” as opposed to “policy”? > > o Software MUST NOT advertise any routes to an eBGP peer without an > operator configuring a policy. > >Are you proposing an automatic detection method for sensing if operator has >configured policy? >How do you sense it? Does the software sense presence or absence of lines of >code in a policy function? >What if operator has encoded a bad policy that simply says accept any route >from any neighbor? >Is the software required to attempt to catch that? > >The second bullet should tie into the first bullet. It can say, >“Software MUST NOT advertise any routes that are marked ‘invalid’ in the >Adj-RIB-In to an eBGP peer.
Hi Kotikalapudi, thanks for you comments. We proposing to change the first two lines to remove the inconsistencies: - Software MUST mark any routes from an EBGP peer as 'invalid' in the Adj-RIB-In, if no import policy was configured. - Software MUST NOT advertise any routes to an EBGP peer, if no export policy was configured. I think that policy detection, verification or undesirable operator configurations are outside the scope of this document. >What about the FIB? Should the doc also say, >“Software MUST NOT install in the FIB any routes that are marked ‘invalid’ in >the Adj-RIB-In”? I don't think this is needed. In a route is invalid in the Adj-RIB-In, it won't be considered in the route selection process, and will not be installed in the FIB. >We also need to distinguish between ‘invalid’ due to RPKI/ROA origin >validation vs. ‘invalid’ due to BGP-sans-policy. >If ‘invalid’ due to RPKI/ROA, the route may be installed and advertised if >there is no alternative route (for that prefix). >(At least during the early adoption phase.) If the route is invalid in Adj-RIB-In, it wouldn't even reach any next steps in the decision making process as above. So any further mechanisms such as origin validation, prefix filtering, or evaluating routing policies configured by the operator would not even be reached. > o Software MUST NOT require a configuration directive to operate in > this mode. > >Simply saying “this mode” is ambiguous. Do you mean to say “the above two >functions >(1st and 2nd bullets) are innate behavior (default) and MUST NOT require a >configuration directive”? The opening line scopes the bulleted requirements to clarify the use of "this": "The following requirements apply to the solution described in this document:" We propose to change the line in question as follows to clarify: - Software MAY provide a configuration option to disable this security capability. > o Software MUST provide protection from internal failures preventing > the advertisement and acceptance of routes. > >Is this about redundancy and reliability? If so, does this belong in this >document? >If does belong here, providing an example or two regarding how it is done >would be useful. Agreed, we changed MUST to SHOULD. The idea is that the BGP speaker would still follow the described behavior in the event of a software failure, for example if the implementation has a separate policy engine process, instead of advertising and accepting everything. >Quoting from the intro: >“Routing leaks > [I-D.ietf-idr-route-leak-detection-mitigation] are part of the > problem,….” > >RFC 7908 defines route leaks. The draft you have cited describes a solution >for route leaks. No harm citing both. Added. Thanks, Greg -- Greg Hankins <[email protected]> _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
