Subject: Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 2 Dec 2016 02:20:48 +0000

Randy:

Hi!

Do you think we can get an update out for this document soon?  I just put the BGPsec spec up for the Jan/5 IESG Telechat, and it would be great if we could get this document in as well.

Thanks!

Alvaro.

On 11/8/16, 12:28 AM, "Randy Bush" <[email-masked]<mailto:[email-masked]>> wrote:

thanks for the best review this has had in a while.  i am not ignoring
you; and may even get a version out for next week.  but no promises, as
i suspect you folk will think that having a solid ietf network next week
is more important :)

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Dec 2016 07:56:25 -0800

great review.  thanks!

> 1. Why is this document a BCP?  A BCP is a document that describes
> “the community's best current thinking…on what is believed to be the
> best way to perform some operations” [rfc2026].  This document meets
> that bar of the description, but there is clearly not a lot of
> practice behind the considerations – which I think is reflected in the
> lack of significant comments from the WG.  I would prefer if this
> document as Informational, pending some actual experience.  But I’ll
> settle for a good explanation (to be also included in the Shepherd’s
> write-up) of why BCP.

because it is, as you quote, the community's best current thinking…on
what is believed to be the best way to perform some operations

as to significant comments from the wg, welcome to sidr; it's either a
poolpah or silent assent.

> 2. This document, as a companion of draft-ietf-sidr-bgpsec-protocol,
> is the only place where Operational (or Management) Considerations are
> discussed.  However, important items recommended in RFC5706
> (Guidelines for Considering Operations and Management of New Protocols
> and Protocol Extensions), such as migration or fault management are
> not covered anywhere.  Given the tone and current content of this
> document, I don’t think extending it is the way forward -- so, in my
> review of draft-ietf-sidr-bgpsec-protocol [1], I asked the authors to
> include an Operations and Management Section there and to consider
> using this document as the base.  Merging this document into
> draft-ietf-sidr-bgpsec-protocol is an action that the
> WG/authors/Chairs/Shepherds should consider.  While that is my
> preferred solution, I will move forward with publication of this
> document if that is the consensus.

sidr has been separating protocol from ops all the way down the line,
e.g. in origin validation.  heck, you have separated (protocol == sidr)
from (ops == sidrops).

> M1. In Section 5, you wrote: “As they are not formally verifiable, an
> eBGP listener SHOULD NOT strongly trust unsigned security markings
> such as communities received across a trust boundary.”  After reading
> this piece of text several times, I think I picked up on the subtle
> message: don’t trust unsigned *security markings* -- vs what I got
> from the first n-1 readings: don’t trust communities.  I think that
> this paragraph would greatly benefit from more details or an example
> related to security markings.

   BGPsec does not sign over communities, so they are not formally
   trustable.  Additionally, outsourcing verification is not prudent
   security practice.  Therefore an eBGP listener SHOULD NOT strongly
   trust unsigned security signaling, such as communities, received
   across a trust boundary.

> M2. In Section 7. (Routing Policy): “As BGPsec will be rolled out
> over…a long time.  Hence a normal operator's policy SHOULD NOT be
> overly strict, perhaps preferring Valid paths and giving very low
> preference, but still using, Not Valid paths.”  This recommendation
> concerns me because “Not Valid” talks directly to the fact that the
> announcement is, well, not valid – vs just unable to be verified
> (because there’s no BGPsec_Path attribute, for example).  The next
> sentence is a reflection of my concern: “Operators should be aware
> that accepting Not Valid announcements…will often be the equivalent of
> treating them as fully Valid.”  I-D.sidr-bgpsec-protocol suggests the
> same thing (in 5.1, pointing to this document).  I am left with the
> question: why validate at all if the BCP recommendation is to use all
> announcements no matter the state?  I obviously realize that it is
> still early days – maybe it is too early for a BCP document if the
> “practice” is not there yet…

this is the result of a primrose path and, as i am a naggumite, i am
quite willing to be strict here.  but how we got here was; paths are
either valid or not; you do not know if it is not valid because of lack
of current rpki data or an attck (much blood spilled here).  once you
have swollowed this reduced signaling koolaid, you could have a not
valid path because you just don't have the data, a weaker state than
failure.  this left us wussing out on what to do with them in best path
choice.

how about s/SHOULD NOT/MIGHT NOT/?

or, as i am a naggumite, i am willing to say just drop the suckers, and
blame it on you :)

> M3. Also in Section 7: “…signed paths that are Not Valid and yet
> propagated…SHOULD have their signatures kept intact…” Section
> 4.2. (Constructing the BGPsec_Path Attribute) of
> draft-ietf-sidr-bgpsec-protocol says: “a Signature_Block which is not
> deemed 'Valid'…such Signature_Blocks MUST NOT be removed.”  The
> “SHOULD” in this document is at odds with the “MUST NOT” in the BGPSec
> spec; please s/SHOULD/MUST, or (even better) s/SHOULD/should.

   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.

> M4. Still in Section 7: “To prevent exposure of the internals of BGP
> Confederations [RFC5065], a BGPsec speaker which is a Member-AS of a
> Confederation MUST NOT sign updates sent to another Member-AS of the
> same Confederation.”  This is another case where the BGPSec spec says
> something different: Section 4.3. (Processing Instructions for
> Confederation Members) presents a mandatory mechanism that includes
> signing, but not necessarily validating.  BTW, if the updates are not
> signed, then the signed path would be broken, even if all the routers
> in the path support BGPSec, right?  Is that the recommendation?

it is common for a bgp confederation to include private ASs for which
there can be no unique authorative router credentials in the rpki.
hence i am suspicious of the protocol spec.

> M5. In Section 8: “…routers' clocks MUST be correct…” What does this
> mean?  Correct with respect to what?  Later (2 paragraphs) you do
> mention RFC5905, should that be the reference here?  Maybe make the
> clock topic one paragraph to avoid confusion.

   As a router must evaluate certificates and ROAs which are time
   dependent, routers' clocks MUST be correct to a tolerance of
   approximately an hour.  The common approach is for operators to
   deploy servers that provide time service, such as [RFC5905], to
   client routers.

> R1. The reference to BGPsec should be draft-ietf-sidr-bgpsec-protocol
> (and not I-D.ietf-sidr-bgpsec-overview).  I think it is ok to
> reference I-D.ietf-sidr-bgpsec-overview in the Suggested Reading as an
> Informative reference.  Similarly, rfc6480, rfc6481 and rfc6482 should
> be made Informative as well.

ack

> R2. Section 7: “This implies that the route server creates signatures
> per client including its own AS in the BGPsec_Path and the target
> ASes, see 2.2.2 of [I-D.ietf-idr-ix-bgp-route-server].”  I think this
> reference is not correct because I-D.ietf-idr-ix-bgp-route-server
> doesn’t say anything about BGPSec.  That section does say the
> opposite: “the route server SHOULD NOT prepend its own AS number to
> the AS_PATH segment nor modify the AS_PATH segment in any other way”.
> Maybe point at 4.2 of draft-ietf-sidr-bgpsec-protocol instead.

   A route server is usually 'transparent', i.e. does not insert an AS
   into the path so as not to increase the AS hop count and thereby
   affect downstream path choices.  But, with BGPsec, a client router R
   needs to be able to validate paths which are forward signed to R.
   But the sending router can not generate signatures to all the
   possible clients.  Therefore a BGPsec-aware route server needs to
   validate the incoming BGPsec_Path, and to forward updates which can
   be validated by clients which must therefore know the route server's
   AS.  This implies that the route server creates signatures per client
   including its own AS in the BGPsec_Path, forward signing to each
   client AS, see [I-D.ietf-sidr-bgpsec-protocol].  The route server
   uses pCount of zero to not increase the effective AS hop count,
   thereby retaining the intent of 'transparency'.

> R3. RFC6811 should be a Normative reference.

ack

> Minor:
> m1. The IPv4 examples in Section 7 should use addressed from rfc6890.

can't.  need more than a /24.  we went through this in origin
validation.

> m2. In Section 7: “Therefore, unless local policy ensures otherwise, a
> signed path learned via iBGP MAY be Not Valid.”  That “MAY” is not
> normative in this context, but it is stating a fact: s/MAY/may.

ack

> m3. Also in Section 7: “If it is known that a BGPsec neighbor is not a
> transparent route server, and the router provides a knob to disallow a
> received pCount (prepend count, zero for transparent route servers) of
> zero, that knob SHOULD be applied.”  There are other cases when pCount
> 0 is ok, draft-ietf-sidr-as-migration for example.  I know that
> “SHOULD” allows other cases, but maybe working in the router server as
> an example might be an improvement.

   If it is known that a BGPsec neighbor is not a transparent route
   server, or is otherwise validly using pCount=0 (e,g, see
   [I-D.ietf-sidr-as-migration]), and the router provides a knob to
   disallow a received pCount of zero, that knob SHOULD be applied.
   Routers should disallow pCount 0 by default.

> m4. Section 9. (Security Considerations): “The major security
> considerations for the BGPsec protocol are described in
> [I-D.ietf-sidr-bgpsec-protocol].”  Are there other security
> considerations not mentioned there?

uh, none come to mind with only one cuppa.

> Nits:
> n1. Introduction: “…origin validation…will occur over the next two to
> three years and that BGPsec will start to deploy well after that.”
> Recommendation: avoid specific timeframes, be a little vaguer
> (short/medium/long term).  I noticed that the first version of
> draft-ymbk-bgpsec-ops also mentioned “two to five years” (in 2011!).

well, we were using the ipv6 time service, clearly a mistake :)

   BGPsec, [I-D.ietf-sidr-bgpsec-protocol], is a new protocol with many
   operational considerations.  It is expected to be deployed
   incrementally over a number of years.  As core BGPsec-capable routers
   may require large memory and/or modern CPUs, it is thought that
   origin validation based on the RPKI, [RFC6811], will occur over some
   years and that BGPsec will start to deploy after that.

> n2. s/ client cone, i.e. an RR client or the transitive closure of
> their customers' customers' customers' etc./ client cone, i.e. an RR
> client or reachable transitively through one of them.

   In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec
   enabled if and only if there are eBGP speakers in their client cone,
   i.e. an RR client or the transitive closure of a client's customers'
   customers' customers' etc.

> n3. “As the vast majority (84%) of ASs are stubs, and they announce
> the majority of prefixes…” A reference would be nice.

lost in time.  removed.  should rerun measurement, but not today.

> n4. “Because of possible RPKI version skew…”  I guess you mean lack of
> sync…

i don't think so.  i take lack of sync meaning i can not reach a cache
or publisher.  version skew could occur when timers have not yet fired.
but it's fuzzy.

> n5. Security Considerations.  Please write something along the lines
> of: “This document describes operational considerations for the
> deployment of BGPsec.  The security considerations for BGPsec are…”

9.  Security Considerations

   This document describes operational considerations for the deployment
   of BGPsec.  The security considerations for BGPsec are described in
   [I-D.ietf-sidr-bgpsec-protocol].

i do not plan to push the button until you and chairs say we're
converged.

randy

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 2 Dec 2016 17:19:49 +0000

On 12/2/16, 10:56 AM, "Randy Bush" <[email-masked]> wrote:

Randy:

Hi!

I’m fine with your comments, proposed text.  Just a couple of more replies below.

Thanks!

Alvaro.

…

> blame it on you :)

“naggumite” – it took me a while to figure this out… ;-)

My biggest problem with the original text is the normative “SHOULD NOT”, so changing that to “might not” works for me as you’re describing a fact of what may happen in the initial deployments…

I am also happy to take the blame for dropping invalid stuff. ;-)

…

> hence i am suspicious of the protocol spec.

As luck would have it, the protocol spec is in IETF Last Call right now. ;-)

Short of changing the spec, we can’t have conflicting behavior being specified.

…

> converged.

Except for the Confederations point above, I think we are.

Thanks!

Alvaro.

---

From: Randy Bush <[email-masked]>
Date: Fri, 2 Dec 2016 09:23:49 -0800

I'll wait to push when until have heard from the protocol editors. 

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Dec 2016 11:26:51 -0800

sig.  wrong docco.  will push this one.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Dec 2016 11:31:24 -0800

> “naggumite” – it took me a while to figure this out… ;-)

one of the times jon postel and i disagreed.  imiho being liberal in
what you except is the road to entropic death.

> My biggest problem with the original text is the normative “SHOULD
> NOT”, so changing that to “might not” works for me as you’re
> describing a fact of what may happen in the initial deployments…
> 

this is the bit i wanna tweak when i get off the phone with untied

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Dec 2016 12:37:44 -0800

unless someone screams

   As BGPsec will be rolled out over years and does not allow for
   intermediate non-signing edge routers, coverage will be spotty for a
   long time.  This presents a dilemma; should a router evaluating an
   inbound BGPsec_Path as Not Valid be very strict and discard it?  On
   the other hand, it might be the only path to that prefix, and a very
   low local-preference would cause it to be used and propagated only if
   there was no alternative.  Either choice is reasonable, but we
   recommend dropping because of the next point.

   Operators should be aware that accepting Not Valid announcements, no
   matter the local preference, will often be the equivalent of treating
   them as fully Valid.  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 Not Valid announcement for
   10.0.666.0/24 from neighbor I.  If local policy on the router is not
   configured to discard the Not Valid announcement from I, then longest
   match forwarding will send packets to neighbor I no matter the value
   of local preference.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 6 Dec 2016 22:31:33 +0000

Randy:

Hi!

In thinking about this point some more…what about draft-ietf-sidr-slurm?  Isn’t that supposed to address the private space?

Thanks!

Alvaro.

On 12/2/16, 12:56 PM, "Randy Bush" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Randy Bush <[email-masked]>
Date: Tue, 06 Dec 2016 16:40:23 -0800

alvaro,

> In thinking about this point some more…what about
> draft-ietf-sidr-slurm?  Isn’t that supposed to address the private
> space?
> 

if a private-as router in confederation C signs from that as, others in
the confed C may (or may not) have the slurmy data.  but assuredly, when
that route finally makes its way out to the global internet, there will
be a signature in the path which no one can validate.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 06 Dec 2016 21:41:47 -0800

> hence i am suspicious of the protocol spec.

i recant.  the protocol spec 4.3 says the intra-confed path elements are
stripped before exporting outside the confed.

   To prevent exposure of the internals of BGP Confederations [RFC5065],
   a BGPsec speaker exporting to a non-member removes all intra-
   confederation Secure_Path segments.  Therefore signing within the
   confederation will not cause external confusion even if non-unique
   private ASs are used.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Dec 2016 13:07:35 -0800

otoh, private AS numbers are used in non-confed topologies, e.g. the bgp
stub customer who uses a private AS.  they should not sign of course.
but once i receive their announcement and strip the private AS,
can/should i sign?  i just looked at bgpsec-protocol and found no
guidance.

randy

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 9 Dec 2016 21:51:37 +0000

Hi!

Yes, there should be something about private ASNs in the protocol spec.

It would be nice to also see some operational guidance in this document.

Alvaro.

On 12/7/16, 7:07 PM, "Randy Bush" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Randy Bush <[email-masked]>
Date: Fri, 09 Dec 2016 13:57:11 -0800

> can/should i sign?  i just looked at bgpsec-protocol and found no

first the protocol spec needs to make clear if the real AS can proxy
sign for a connected private AS.  then i can hack the ops doc.

seems to me that, as the real AS is required to strip the private AS
from the path, the real AS should be able to proxy sign.  but then
who has the cert to create the roa, etc.?

randy

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 9 Dec 2016 22:01:38 +0000

Yes, I agree.  I just sent a message to the authors of the protocol spec (cc’d the WG) along the same lines.

On 12/9/16, 7:57 PM, "Randy Bush" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: joel jaeggli <[email-masked]>
Date: Sun, 11 Dec 2016 14:15:58 -0800

> can/should i sign?  i just looked at bgpsec-protocol and found no

from that vantage point you are the origin. it's not clear to me that a
customer  relationship is substantively then if you do this internal to
your org. operationally the'yre probably also registering route objects,
issuing LOAS and operating on behalf of the private ASN.

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

---

From: Randy Bush <[email-masked]>
Date: Mon, 12 Dec 2016 10:32:49 -0800

> from that vantage point you are the origin. it's not clear to me that
> a customer relationship is substantively then if you do this internal
                                          ^ did you drop "different?"
> to your org. operationally the'yre probably also registering route
> objects, issuing LOAS and operating on behalf of the private ASN.

almost.  while they _may_ be registering route objects, it is unlikely
they are signing contracts on behalf of the customer.  different transit
providers provision customers using private ASs in different ways (doh).

but i think essentially we are in agreement.  as far as bgpsec and
roa-based origin validation go, it would probably be good to specify how
the transit operator proxies for the private AS customer.

but this is the ietf.  i have faith that someone can come up with a
corner case where this should not be done. :)

randy