Subject: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

From: Chris Morrow <[email-masked]>
Date: Wed, 01 Jun 2016 14:52:29 -0400

Howdy WG folks,
Please take this note as the start of the 2wk WGLC period for:
  <https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-07>

Abstract:
  "Deployment of the BGPsec architecture and protocols has many
   operational considerations.  This document attempts to collect and
   present the most critical and universal.  It is expected to evolve as
   BGPsec is formalized and initially deployed."

This is a relatively short document, 8 pages, full of wonder and
excitement! I hope that the wg members have read it (it's been through
8+ revisions) and that they will re-read it quickly, provide comments
as appropriate and ideas on preparedness for publication or not.

Thanks for you time and attention to this matter,

-Chris
co-chair-persona

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 8 Jun 2016 22:19:54 -0400

No responses at all.

Come on folks.  It’s a short document, like Chris says.

You should be able to read and comment without much trouble.

—Sandy, speaking as one of the wg co-chairs

On Jun 1, 2016, at 2:52 PM, Chris Morrow <[email-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 15 Jun 2016 09:35:43 -0400

It is a short document.  The sentences are not complicated.  It reads quickly.

There’s been little/no wg comment on this, certainly no controversy, over the lifetime of the draft.

But still.

Please.  Pretty please.  Pretty please with sugar on top.  Pretty please with a cherry on top.

Could we get some feedback that this document is ready for publication?

---

From: Aris Lambrianidis <[email-masked]>
Date: Thu, 16 Jun 2016 00:27:12 +0900

> On 15 Jun 2016, at 22:35 , Sandra Murphy <[email-masked]> wrote:
> 

Hi,

My 0.02 of your favourite currency denomination:

Nits:

Line 94: There’s a typo: “twp” instead of “two”
Line 202: Grammatical error: “it’s” instead of “its”
Line 317: Typo: “see see” instead of “see”

Content:

The middle paragraph of section 6. feels a bit foggy to me:

>  BGPsec protocol capability negotiation provides for a speaker signing
>    the data it sends without being able to accept signed data.  Thus a
>    smallish edge router may hold only its own signing key(s), sign it's
>    announcements, but not receive signed announcements and therefore not
>    need to deal with the majority of the RPKI.  Thus such routers CPU,
>    RAM, and crypto needs are trivial and additional hardware should not
>    be needed.

Here’s what my take of the situation described would be:

“Operators might be utilising hardware with limited resources. In such
cases, BGPsec protocol capability negotiation allows for a resource constrained edge
router to just hold its own signing key(s) and sign its announcements, but not receive
signed announcements. Therefore, the router would not have to deal with the majority of
the RPKI, potentially saving the need for additional hardware."

What is “smallish" is more relative than, say, “resource constrained”.
Perhaps an operator uses a large edge router that is overloaded or just
wants to keep their processing overhead low.

Kind regards,
Aris Lambrianidis

---

From: Sean Turner <[email-masked]>
Date: Wed, 15 Jun 2016 15:40:09 -0500

I read it and think it answer the mail.  Ship it.

spt

> On Jun 15, 2016, at 08:35, Sandra Murphy <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Thu, 16 Jun 2016 09:36:29 +0900

> Line 317: Typo: “see see” instead of “see”

<blush>

> cases, BGPsec protocol capability negotiation allows for a resource
> constrained edge router to just hold its own signing key(s) and sign
> its announcements, but not receive signed announcements. Therefore,
> the router would not have to deal with the majority of the RPKI,
> potentially saving the need for additional hardware."

eenie meenie.  but if it makes you happy, i'll use yours.

randy

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 16 Jun 2016 22:00:45 +0200

Hi,

  I read v09. No objections only minor comments:

line 102: BGPsec need*s* *to* be spoken only

line 104: s/by small edge routers/by resource constrained edge routers/

line 119: *see* [RFC4271]

line 159: s/..../etc./

lines 200-206 seem redudant to lines 208-213

line 202 s/smallish/resource constrained/

line 215: I don't know where the 84% comes from, I suppose it's just a 
more or less arbitrary illustration of "vast majority". I would remove 
the number.

line 234: I would be more explicit: "How this is used in routing is up 
to the operator's local policy, similar to origin validation [RFC6811]."

lines 243-250: This paragraph confused me. What about:

Operators should be aware that controlling Invalid announcements by 
local preference might be delusive. Local preference affects only routes 
to the same set of destinations. Consider having a Valid announcement 
from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for 
10.0.66.0/24 from neighbor I. If the local policy on a router is 
configured to accept Invalid announcements, then both routes will be 
installed, no matter of the value of local preference.

(Btw, I suppose that routes to .666 will be discarded anyway ;)

line 252: It sounds that only edge routers are allowed to speak BGPsec. 
I would weaken and say "Validation of signed paths is usually deployed 
at the eBGP edge."

line 292: s/BGPSEC_Path/BGPsec_Path/

lines 288-295:  The paragraph seems to mix transparent operation and the 
question of validation. What about:

A route server is usually 'transparent'. To operate transparently in an 
environment in which the route server connects BGPsec-enabled peers, the 
route server needs to run BGPsec as well. This implies that the route 
server creates signatures per client including its own AS in the 
BGPsec_Path and the target ASes. However, increasing the AS hop count 
reduces the likelihood of best path selection. See 2.2.2 of 
[I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route 
server uses pCount of zero to not increase the effective AS hop count.

Furthermore, a BGPsec-aware route server needs to validate the incoming 
BGPsec_Path but should not drop invalids. In case the client speaks 
BGPsec the route server should just forward updates to clients which 
then validate . In case the client does not speak BGPsec, the route 
server reconstructs the AS_PATH and may signal the validation outcome 
using communities.

line 300: s/Routers should default to this knob disallowing pCount 0./Routers should disallow pCount 0 by default./

line 346: I would rephrase: "Operators should deploy servers that 
provide time service, such as [RFC5905], to client routers."

Cheers
  matthias

-- 
Dr. Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 23 Jun 2016 19:59:15 +0200

Hi Randy,

  one more: Can you please replace "Invalid" by "Not Valid", because 
this is the notation defined in draft-ietf-sidr-bgpsec-protocol-17.

Thanks
  matthias

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 Jun 2016 22:12:50 +0200

matthias,

> this is the notation defined in draft-ietf-sidr-bgpsec-protocol-17.

done.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 24 Jun 2016 09:34:47 +0200

>   I read v09. No objections only minor comments:

i hacked in many of these changes, though i think most did not really
change anything other than an alternate way of saying the same thing.
but i just do not want to see this go on an on interminably.  and at
least you reviewed it.  thanks!

randy

---

From: Matthias Waehlisch <[email-masked]>
Date: Fri, 24 Jun 2016 09:55:38 +0200

Thanks! No further comments from my side. Looing forward to publication.

Cheers
  matthias

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Jun 2016 09:55:56 -0400

Howdy folks, since we got some review and action and re-action... and this
all seems quite positive, let's send this along for publication now.
(today).

thanks!
-chris