Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 03 Jan 2017 15:59:16 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-sidr-bgpsec-ops-12: 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-sidr-bgpsec-ops/

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

Update:  I noted when reviewing other sidr drafts on this telechat agenda
that this draft treats 2119 keywords differently than the other drafts.
That is, this draft explicitly excludes lower case versions of the 2119
keywords, while the other related drafts do not. Assuming that these
drafts have the same target audience, I think that will be confusing to
readers.

I am okay with either approach; in fact I somewhat prefer excluding lower
case versions. But I think consistency among a related group of drafts is
more important.

Just a few minor and editorial comments:

-1, first paragraph: "It is thought...": Can you mention "who" thinks it?
Otherwise that reads as "weasel words".

-1, third paragraph: Please consider writing out "also known as"

-4, first paragraph: I found "either" followed by "and/or" a bit
confusing. I suggest simply dropping the word "either".

-4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended
to offer permission, or describe reality? (The latter should not use a
2119 keyword.)

-4, last paragraph: "a prudent operator will..." sounds like it might be
worthy of a SHOULD.

-6, first paragraph: "SHOULD/MUST only" constructions tend to be
ambiguous. In this case, are we saying SHOULD only originated signed
announcements, as opposed to unsigned announcements? Or as opposed to
validating received assignments? If the latter, then the "need not
validate" seems to weaken the SHOULD.

-6, last paragraph: Can something be cited for the 84% assertion?

-7, paragraph 6: This seems to say that signed paths MUST be signed. Does
the "MUST be signed if sent to external BGP speakers" mean that the
existing signature must not be stripped (as stated more weakly in the
previous sentence), or does it mean the sender must re-sign the path?

-7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid." seems
like a statement of fact.

-12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as
needed to understand this document. That suggests it should be a
normative reference. 

-

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Jan 2017 11:00:13 +0900

thanks for the review.

> Update: I noted when reviewing other sidr drafts on this telechat
> agenda that this draft treats 2119 keywords differently than the other
> drafts.  That is, this draft explicitly excludes lower case versions
> of the 2119 keywords

which is, i believe, the current wisdom; see long discussion on ietf
list.

> while the other related drafts do not.

have fun with that. :)

> -1, first paragraph: "It is thought...": Can you mention "who" thinks
> -it?

phrase removed

> -1, third paragraph: Please consider writing out "also known as"

rich got that

> confusing. I suggest simply dropping the word "either".

   As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers
   are either capable of generating their own public/private key-pairs
   and having their certificates signed and published in the RPKI by the
   RPKI CA system, and/or are given public/private key-pairs by the
   operator.

but the router(s) might not be capable of generating key-pairs.  they
might, they might not, the op may generate or not, or both.  an absurd
corner case might be that a router with two ASs has the as0 key stuffed
by the as0 noc, and the as1 key is generated on device because that is
the as1 policy.

> to offer permission, or describe reality? (The latter should not use a

sure

> -4, last paragraph: "a prudent operator will..." sounds like it might be

given the previous, how about lower case should

> validate" seems to weaken the SHOULD.

   An edge site which does not provide transit and trusts its
   upstream(s) may only originate a signed prefix announcement and not
   validate received announcements.

> -6, last paragraph: Can something be cited for the 84% assertion?

easier to remove it.  actually, i thought i had done so already; which
causes me to worry if i lost other edits.

> previous sentence), or does it mean the sender must re-sign the path?

   Because of possible RPKI version skew, an AS Path which does not
   validate at router R0 might validate at R1.  Therefore, signed paths
   that are Not Valid and yet propagated (because they are chosen as
   best path) should have their signatures left intact and MUST be
   signed if sent to external BGPsec speakers.

i am not seeing where bgpsec stripping was suggested; in fact, the
opposite.  if router r0 receives a signed path and intends to pass that
signed path to the next listener, r0 must sign the path.  i am at a loss
to understand your question.  clue bat please.

> -7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid."
> seems like a statement of fact.

are you suggesting to downcase it?  i will assume so.

> needed to understand this document. That suggests it should be a

ennie meenie.  i think some other reviewer had me push refs around.  i
don't have a dog in this fight.  my personal opinion would be that
overview is informative and the protocol spec itself is normative.

again, thanks.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Jan 2017 11:03:21 +0900

i posted -13 so iesg has fresh

randy

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 4 Jan 2017 12:49:43 +0000

On 1/3/17, 9:00 PM, "Randy Bush" <[email-masked]> wrote:

| | -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as

| | needed to understand this document. That suggests it should be a

| | normative reference.

|

| ennie meenie.  i think some other reviewer had me push refs around.  i

| don't have a dog in this fight.  my personal opinion would be that

| overview is informative and the protocol spec itself is normative.

I agree.  In fact, it was me who asked to move I-D.ietf-sidr-bgpsec-overview to Informative as the reference to the spec (draft-ietf-sidr-bgpsec-protocol) is the Normative one.

In this case, we don’t want to make I-D.ietf-sidr-bgpsec-overview a Normative reference because it is an Informational document and would result in a downref (resulting in more process, and that document is not ready yet).

Alvaro.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 04 Jan 2017 10:41:51 -0600

On 4 Jan 2017, at 6:49, Alvaro Retana (aretana) wrote:

> I agree.  In fact, it was me who asked to move 
> I-D.ietf-sidr-bgpsec-overview to Informative as the reference to the 
> spec (draft-ietf-sidr-bgpsec-protocol) is the Normative one.
>
>
>
> In this case, we don’t want to make I-D.ietf-sidr-bgpsec-overview a 
> Normative reference because it is an Informational document and would 
> result in a downref (resulting in more process, and that document is 
> not ready yet).
>
>

The issue I saw is that section 2 says readers are expected to 
understand bgpsec, and cites the overview for that purpose. Perhaps it 
should cite the protocol doc for the "expected to understand" part, and 
them mention separately that the overview provides, well, an overview?

Ben.

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Jan 2017 01:54:15 +0900

> should cite the protocol doc for the "expected to understand" part

ok.  done.  i would be happier if that document was easier to read and
more concise.

i just pushed

randy

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 04 Jan 2017 10:58:54 -0600

Thanks for the quick response.

On 3 Jan 2017, at 20:00, Randy Bush wrote:

> have fun with that.

I plan to mention that when I write up my reviews of the other two :-)

I agree with the lower case exclusion. I merely thought the working 
group might want to be consistent on the cluster of drafts. (Assuming 
they are really a cluster--I could see an argument that the protocol and 
overview drafts are for a separate audience than the bgp.)

[...]

> by the as0 noc, and the as1 key is generated on device because that is

I merely meant that "either" seemed odd for non-exclusive options. I 
take your argument to mean that the options really are non-exclusive.

> given the previous, how about lower case should

That would not seem to change anything :-) My point was that the 
language seemed stated in a way that _might_ justify a 2119 keyword. If 
you don't think so, then I'm fine with the current wording.

>    validate received announcements.

That's much more clear, thanks.

[...]

> to understand your question.  clue bat please.

Sorry, I did not mean that stripping was suggested; the previous phrase 
(non-normatively) recommends against stripping. My question is, since 
the subject of the sentence is "signed paths" whether the "MUST be 
signed" language means "MUST NOT strip the signature" (which I suspect 
to be the case), or something else.

> are you suggesting to downcase it?  i will assume so.

Yes, sorry.

> overview is informative and the protocol spec itself is normative.

As I mentioned in response to Alvaro's comment: Maybe section 2 should 
cite the protocol rather than the overview? (Perhaps with a separate 
mention that the overview is available.)

Ben.

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Jan 2017 10:29:31 +0900

>>    are either capable of generating their own public/private
>>    key-pairs and having their certificates signed and published in
>>    the RPKI by the RPKI CA system, and/or are given public/private
>>    key-pairs by the operator.
>> 
>> might, they might not, the op may generate or not, or both.  an
>> absurd corner case might be that a router with two ASs has the as0
>> key stuffed by the as0 noc, and the as1 key is generated on device
>> because that is the as1 policy.
> 

ok, i will drop the either.

>>> -4, last paragraph: "a prudent operator will..." sounds like it
>>> might be worthy of a SHOULD.
>> 
> language seemed stated in a way that _might_ justify a 2119
> keyword.

ok, upcased SHOULD

>>> -7, paragraph 6: This seems to say that signed paths MUST be
>>> signed. Does the "MUST be signed if sent to external BGP speakers"
>>> mean that the existing signature must not be stripped (as stated
>>> more weakly in the previous sentence), or does it mean the sender
>>> must re-sign the path?
>> 
>>    validate at router R0 might validate at R1.  Therefore, signed
>>    paths that are Not Valid and yet propagated (because they are
>>    chosen as best path) should have their signatures left intact and
>>    MUST be signed if sent to external BGPsec speakers.
>> 
>> opposite.  if router r0 receives a signed path and intends to pass
>> that signed path to the next listener, r0 must sign the path.  i am
>> at a loss to understand your question.  clue bat please.
> 
> Sorry, I did not mean that stripping was suggested; the previous
> phrase (non-normatively) recommends against stripping. My question is,
> since the subject of the sentence is "signed paths" whether the "MUST
> be signed" language means "MUST NOT strip the signature" (which I
> suspect to be the case), or something else.

how about

   As the mildly stochastic timing of RPKI propagation may cause version
   skew across routers, an AS Path which does not validate at router R0
   might validate at R1.  Therefore, signed paths that are Not Valid and
   yet propagated (because they are chosen as best path) MUST NOT have
   signatures stripped and MUST be signed if sent to external BGPsec
   speakers.

if not, use larger clue bat

> cite the protocol rather than the overview?

done

randy

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 05 Jan 2017 10:05:21 -0600

> if not, use larger clue bat

It's likely I have this particular bat by the wrong end.

In the last sentence, does "MUST be signed" mean it must have a 
signature (which would seem to make "MUST NOT strip" and "MUST be 
signed" redundant), or does it mean the propagating router must add it's 
own signature in addition to the existing one(s)?

Ben.

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Jan 2017 07:14:14 +0900

>>> phrase (non-normatively) recommends against stripping. My question
>>> is, since the subject of the sentence is "signed paths" whether the
>>> "MUST be signed" language means "MUST NOT strip the signature"
>>> (which I suspect to be the case), or something else.
>> 
>> how about
>> 
>>    As the mildly stochastic timing of RPKI propagation may cause
>>    version skew across routers, an AS Path which does not validate at
>>    router R0 might validate at R1.  Therefore, signed paths that are
>>    Not Valid and yet propagated (because they are chosen as best
>>    path) MUST NOT have signatures stripped and MUST be signed if sent
>>    to external BGPsec speakers.
>> 
> signed" redundant), or does it mean the propagating router must add
> it's own signature in addition to the existing one(s)?

yes, it must preserve the signed path and add its own signature.

randy

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 05 Jan 2017 16:18:08 -0600

> yes, it must preserve the signed path and add its own signature.

Thanks, that helps. Would it make the last sentence say something to the 
effect of "... and MUST additionally be signed by the propagating 
router."?

Ben.

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Jan 2017 07:24:27 +0900

> Thanks, that helps. Would it make the last sentence say something to
> the effect of "... and MUST additionally be signed by the propagating
> router."?

alvaro has asked me to stop editing

randy

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 05 Jan 2017 16:40:07 -0600

> alvaro has asked me to stop editing

Understood :-)