Subject: Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

From: Job Snijders <[email-masked]>
Date: Sat, 13 Aug 2016 18:31:55 +0200

On Thu, Nov 12, 2015 at 11:49:11PM -0700, Ebben Aries wrote:
> Yes, support - Thank you for putting this together
> 
> Few minor comments
> 
> Section 1
> - Minor spelling/wording errors
>   - s/guidace/guidance/g
>   - s/with the requiring the explicity/with requiring the explicit/

Fixed.

> Section 3
> - "Software MUST NOT require a configuration directive to operate in
> this mode." - Since there could very well be a configuration option to
> disable this capability (as noted in this same section), this should
> rather be worded that this mode is default.  It could very well be
> delivered via a default and/or hidden configuration directive. (You may
> also want to re-enable this capability after previously disabling it)

Would "Software MUST operate in this mode by default." be a better
phrasing?

Kind regards,

Job

---

From: Ebben Aries <[email-masked]>
Date: Mon, 15 Aug 2016 18:26:22 -0600

>>   - s/with the requiring the explicity/with requiring the explicit/

ack

> Would "Software MUST operate in this mode by default." be a better

sounds good to me

Thx

/ebben

> Kind regards,
> 
> Job
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 17 Aug 2016 12:26:32 +0000

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.

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”?

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

   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”? 

   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. 

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. 

Thanks.

Regards,
Sriram

---

From: Greg Hankins <[email-masked]>
Date: Wed, 17 Aug 2016 11:46:02 -0400

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

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

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

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

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

>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-masked]>

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 23 Aug 2016 21:21:51 +0000

Greg,

Thanks for your responses. You may call me Sriram - name I go by.
Comments below.

Sriram

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

Ok, sounds good.

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

Yes, agree.

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

Let us say, all received routes were ok (i.e. not marked 'invalid') initially because ingress policy is there.
Now route engine (RE) does origin validation (OV) and marks a route 'invalid' (see RFC 6811) in the RIB
(i.e. saves the OV result for possible further use later) .
The next time this RIB entry (route) is considered in the decision process, there may be 
confusion if it is policy 'invalid' or OV 'invalid'. 
I think the labeling of routes needs to distinguish between the two (RFC6811 vs. policy). 

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

Some rewording may be helpful here, such as:
Internal failures elsewhere in the router SHOULD not affect this security feature.
For example, ...[provide an example if you wish].

Sriram

---

From: Brian Dickson <[email-masked]>
Date: Tue, 23 Aug 2016 17:32:34 -0700

Sriram & Greg:

I think the underlying issue is some terms used in *implementations*, which
do not match exactly with the BGP protocol specifications (1771 and 4271).

There are a few terms which get used interchangeably, unfortunately, which
need some disambiguation (IMHO).
Those terms are:
- unfeasible
- withdrawn
- unresolvable
- invalid
- (excluded)
and now includes
- OV-invalid
- (this document's marking of "no-policy-invalid")

Whether the same "bit" in the internal representation should/could be used
is pretty important; if different implementations conflate distinct
situations, interoperability could be affected.

I believe it is the case that at least the two big router vendors used the
labels "invalid"/"valid" as a representation of "unresolvable", which has
lead to this confusion.

The RFCs actually use "invalid" to mean that some mandatory attribute is
either missing or malformed, and should temporarily be marked that way,
until withdrawal(s) happen, including from the RIB/FIB.
(I think there are minimum 3 conditions that trigger that in the base spec,
probably more in subsequent BGP attributes/families.)
Invalid is actually an temporary thing, since the affected NRLI should be
purged once other actions are completed.

Unfeasible is aka withdrawn, and is also in effect a temporary thing; once
processed, the unfeasible routes are gone from the in-RIBs and RIB.

Unresolvable is a derived state, based on the NEXT_HOP not being
resolvable.
It doesn't go away automatically, unlike invalid and unlike unfeasible
routes.
It CAN change as a result of state changes on the route specified by the
NEXT_HOP, independent of the NLRI itself.

OV-invalid is similar to, but distinct from, unresolvable, and should NOT
be implemented using the same "bit"/flag.

However, I believe the "unresolvable" and the "no-policy-invalid"
attributes are fine to represent with the same "bit", since neither should
be able to pass Phase 2 of the path selection process.

At some point down the road, a "bis" version of the base spec should be
done, which makes minor revisions to clarify these terms, among other
things. IMHO.

For now, it may be necessary to add clarification/definitions to this
document to make it clear to readers/implementers, what "invalid" means in
this context.

Brian

On Tue, Aug 23, 2016 at 2:21 PM, Sriram, Kotikalapudi (Fed) <
[email-masked]> wrote:

>
> >>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).
> steps in
> Let us say, all received routes were ok (i.e. not marked 'invalid')
> initially because ingress policy is there.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 24 Aug 2016 14:51:51 +0000

>For now, it may be necessary to add clarification/definitions to this document 
>to make it clear to readers/implementers, what "invalid" means in this context.

In the case OV, the marking (in accordance with RFC 6811) needs to be per route 
(regardless of the peer it was received from).

My suggestion for the case of policy/no-policy: 
There can be two overarching flags per peer that can be Red (set) or Green (not set):

1. No-ingress-policy flag:  If Red (set) for a given peer, then all routes 
from that peer will be marked ‘no-policy-invalid’ in the Adj-RIB-in.

2. No-egress-policy flag: If Red (set) for a given peer, 
then no routes will be announced to that peer.

Sriram 
-----------------------------------------------------------------------------------------------------------------

From: Brian Dickson [mailto:[email-masked]] 
Sent: Tuesday, August 23, 2016 8:33 PM
To: Sriram, Kotikalapudi (Fed) <[email-masked]>
Cc: Greg Hankins <[email-masked]>; [email-masked]; Job Snijders <[email-masked]>
Subject: Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject

Sriram & Greg:

I think the underlying issue is some terms used in *implementations*, which do not match exactly with the BGP protocol specifications (1771 and 4271).

There are a few terms which get used interchangeably, unfortunately, which need some disambiguation (IMHO).
Those terms are:
- unfeasible
- withdrawn
- unresolvable
- invalid
- (excluded)
and now includes
- OV-invalid
- (this document's marking of "no-policy-invalid")

Whether the same "bit" in the internal representation should/could be used is pretty important; if different implementations conflate distinct situations, interoperability could be affected.

I believe it is the case that at least the two big router vendors used the labels "invalid"/"valid" as a representation of "unresolvable", which has lead to this confusion.

The RFCs actually use "invalid" to mean that some mandatory attribute is either missing or malformed, and should temporarily be marked that way, until withdrawal(s) happen, including from the RIB/FIB. 
(I think there are minimum 3 conditions that trigger that in the base spec, probably more in subsequent BGP attributes/families.)
Invalid is actually an temporary thing, since the affected NRLI should be purged once other actions are completed.

Unfeasible is aka withdrawn, and is also in effect a temporary thing; once processed, the unfeasible routes are gone from the in-RIBs and RIB.

Unresolvable is a derived state, based on the NEXT_HOP not being resolvable. 
It doesn't go away automatically, unlike invalid and unlike unfeasible routes.
It CAN change as a result of state changes on the route specified by the NEXT_HOP, independent of the NLRI itself.

OV-invalid is similar to, but distinct from, unresolvable, and should NOT be implemented using the same "bit"/flag.

However, I believe the "unresolvable" and the "no-policy-invalid" attributes are fine to represent with the same "bit", since neither should be able to pass Phase 2 of the path selection process.

At some point down the road, a "bis" version of the base spec should be done, which makes minor revisions to clarify these terms, among other things. IMHO.

For now, it may be necessary to add clarification/definitions to this document to make it clear to readers/implementers, what "invalid" means in this context.

Brian
_____________________