Subject: [GROW] Eric Rescorla's No Objection on draft-ietf-grow-bgp-reject-08: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Tue, 06 Jun 2017 10:50:01 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-grow-bgp-reject-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-reject/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am having a little trouble reading Appendix A.

If I understand correctly, the idea is:

- In version N, you have a behavior X
- In version N+1, you introduce a setting S with default value S=X
- In version N+2 you change the default to S=!X

However, the text says that "installations upgraded from release N+1 will
adhere to the previous insecure behavior"

Do you need to say that in N+1, you save the value S=X so that in N+1, it
continues to apply?

---

From: Job Snijders <[email-masked]>
Date: Wed, 7 Jun 2017 16:34:51 -0700

Hi Eric,

On Tue, Jun 06, 2017 at 10:50:01AM -0700, Eric Rescorla wrote:
> However, the text says that "installations upgraded from release N+1
> will adhere to the previous insecure behavior"
> 
> Do you need to say that in N+1, you save the value S=X so that in N+1,
> it continues to apply?

If in N+1 you save S=X, then in N+2, if S is defined as X, behaviour X
will apply. If S is not defined, or defined otherwise (like with a fresh
install, not an upgrade), you will have !X behaviour.

It kind of depends on the implementation and configuration paradigm
whether this advice can be applicable, hence why we flagged it as "This
appendix is non-normative."

Kind regards,

Job

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Jun 2017 04:05:47 +0200

On Thu, Jun 8, 2017 at 1:34 AM, Job Snijders <[email-masked]> wrote:

> will apply.

Well, yes.

> If S is not defined, or defined otherwise (like with a fresh

Yes.

My question is whether in the N+1/N+2 paradigm you are proposing that in
N+1 you save S=X.

-Ekr

---

From: Job Snijders <[email-masked]>
Date: Thu, 08 Jun 2017 02:13:18 +0000

Yes.

Do you have a proposed sentence that should be added if this isn't clear?

Kind regards,

Job

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Jun 2017 04:35:42 +0200

Perhaps

An implementer could leverage an approach described as "the N+1 and
N+2 release strategy".  In release N+1, the implementer introduces a
new configuration parameter to configure "egbp insecure-mode".  Upon
installation of release N+1, if the value is not configured, an
"insecure" value will be automatically generated and saved to the
configuration, and an implementer could begin to display informational
warnings to the operator that certain parts of the configuration are
incomplete.  Thus, In release N+1, operators of the BGP implementation
become aware that a configurable value exists in the implementation,
and can prepare accordingly.  In release N+2 or later, the default
value becomes "secure".

As a result, any new installation of release N+2 will adhere to this
document.  Installations upgraded from version release N+1 will
adhere to the previous insecure behavior, if no modification was made
to the "ebgp insecure-mode" configuration parameter. Note that versions
upgraded directly from N to N+2 will change their behavior from
"insecure" to "secure".