Subject: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Mon, 02 Jan 2017 05:29:36 -0800

Mirja Kühlewind 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:
----------------------------------------------------------------------

Quick question: I'm by far not an expert here, but I remember that there
used to be some concerns that it is practical not possible to disable
BGPsec once enabled. If that's (still) true, should this be mentioned
here?

---

From: Randy Bush <[email-masked]>
Date: Mon, 02 Jan 2017 22:45:16 +0900

> Quick question: I'm by far not an expert here, but I remember that
> there used to be some concerns that it is practical not possible to
> disable BGPsec once enabled. If that's (still) true, should this be
> mentioned here?

i am not sure what you mean, so let me guess.

an established bgp session has negotiated simplex or duplex bgpsec via
bgp capability exchange.  one can not change the agreement without
tearing down and restarting the session.

a router which is bgpsec enabled, receives a signed path from the left,
but on the right it had a non-sec session, strips the bgpsec info from
the path.

these are discussed in the bgpsec protocol document.  section 6,
appended to save dumster diving, shows some of the operational uses of
this.  do you have suggestions for other examples worth enumerating?

randy

6.  Considerations for Edge Sites

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

   An Operator might need to use hardware with limited resources.  In
   such cases, BGPsec protocol capability negotiation allows for a
   resource constrained edge router to hold only 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.

   As the vast majority (84%) of ASs are stubs, and they announce the
   majority of prefixes, this allows for simpler and less expensive
   incremental deployment.  It may also mean that edge sites concerned
   with routing security will be attracted to upstreams which support
   BGPsec.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 2 Jan 2017 15:01:14 +0100

Hi Randy,

thanks for you quick reply.

I actually might be mixing this up with some discussion about DNSsec a while ago, where the problem was that once enable others will remember that it was supported and will not accept non secured requests anymore. 

But as we are talking about this, could there be a similar case here, where a router is known to support BGPsec and others would ignore/drop non-signed announcements? (Sorry if that’s all discussed in the protocol doc; in this case just ignore my questions ;-); didn’t review the protocol spec yet but it’s the next doc on my list; probably should have read that one first…)

Mirja

> Am 02.01.2017 um 14:45 schrieb Randy Bush <[email-masked]>:
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 03 Jan 2017 00:33:49 +0900

hi mirja,

> could there be a similar case here, where a router is known to support
> BGPsec and others would ignore/drop non-signed announcements?

hmmmm.  as far as i can remember, this has not actually been discussed.

how would a router be known to support bgpsec?  well, if i saw it on a
signed path.  (for the moment, let's ignore changes over time).  but it
might have an out-degree of O(100) and some portion are signed and the
rest not.  the ones that are not signed are due to the peer not
negotiating bgpsec, or that one or the other is configured to not have
the peering be bgpsec.

and it's way too late here for me to do the necessary deep dive into
draft-ietf-sidr-bgpsec-pki-profiles-18.txt to know if i can definitively
identify a router, especially as one router can have multiple ASs and
therefore multiple certs and therefore multiple skis.

maybe someone on the us beast coast has had enough coffee to hit me with
a clue by four when i wake.

randy

---

From: Chris Morrow <[email-masked]>
Date: Mon, 02 Jan 2017 19:35:25 -0500

At Tue, 03 Jan 2017 00:33:49 +0900,
> hmmmm.  as far as i can remember, this has not actually been discussed.

i think this is correct.
(I don't remember discussing something like this in the past)

I can imagine a future where the operations staff decides: "We only do
bgpsec (with peers x, y, z) turn on the knob that requires bgpsec at
peer establishment!"

In that case, if it were to be true, the operator would have chosen to
only do bgpsec and not fallback to normal bgp... The router(s) aren't
really remembering that their peer did bgpsec in the past as much as
requiring the bgpsec capability at peer 'connect'.

> negotiating bgpsec, or that one or the other is configured to not have

I bet with a distant view of one ASN (or all ASN) you could tell, over
time, whom the ASN peers with via 'bgpsec' vs 'bgp'. You MAY choose to
do some policy stuff that says: "ASN X, Y, Z seem to always do bgpsec
with +XX% of their peers in my view of them... so only accept routes
originated by these ASN if the routes arrive on bgpsec-enabled
peerings."

This seems dangerous, today anyway, but maybe tomorrow it'd be more
feasible? I also don't know that you could easily tell: "the router"
vs "the asn", because as you get further away on the network your
entrypoint (and whom in that ASN you hear routes FROM) to the remote
ASN is less guaranteed.

---

From: Randy Bush <[email-masked]>
Date: Tue, 03 Jan 2017 10:37:38 +0900

ok, i have had coffee.

as a bif gedanken experiment, posit a global registry where r0 can say
"i can speak bgpsec."  i am a distant r1 and receive an unsigned path
with r0 in it.
  o did someone before r0 on the path not speak bgpsec, so the path was
    never signed?
  o did someone between us not speak bgpsec, so the path was stripped?
  o was there a monkey in the middle?

i think we did discuss this problem space, and decided that, as long as
we allow islands of partial deployment, and therefore path stripping,
the monkey is on our back.  we might have been wrong in this; but even
with coffee i do not see a way out.

and i do not think the idea of partial path signing, r0 signing a
received unsigned path, would have helped a lot.

it is not clear to me that this is a space where the ops doc can help
much.  i am open to ideas.

randy

---

From: Peter Hessler <[email-masked]>
Date: Tue, 3 Jan 2017 09:39:07 +0100

On 2017 Jan 03 (Tue) at 10:37:38 +0900 (+0900), Randy Bush wrote:
:ok, i have had coffee.
:
:as a bif gedanken experiment, posit a global registry where r0 can say
:"i can speak bgpsec."  i am a distant r1 and receive an unsigned path
:with r0 in it.
:  o did someone before r0 on the path not speak bgpsec, so the path was
:    never signed?
:  o did someone between us not speak bgpsec, so the path was stripped?
:  o was there a monkey in the middle?
:
:i think we did discuss this problem space, and decided that, as long as
:we allow islands of partial deployment, and therefore path stripping,
:the monkey is on our back.  we might have been wrong in this; but even
:with coffee i do not see a way out.
:
:and i do not think the idea of partial path signing, r0 signing a
:received unsigned path, would have helped a lot.
:
:it is not clear to me that this is a space where the ops doc can help
:much.  i am open to ideas.
:
:randy
:

I'm currently not using bgpsec (or rpki for that matter).  BUT, if there
was no path to go back, I would never ever use it.  Destroying my ASN
because I wasn't ready to migrate is a straight-up No Go(tm).

Mistakes will be made.  Rolling back will happen.  Preventing rolling
back will kill the baby and will guarentee this will never be rolled
out.

-- 
Help fight continental drift.

---

From: Chris Morrow <[email-masked]>
Date: Tue, 03 Jan 2017 09:26:33 -0500

At Tue, 3 Jan 2017 09:39:07 +0100,
> because I wasn't ready to migrate is a straight-up No Go(tm).

yup, I think this was part of the original thought process for bgpsec.

> back will kill the baby and will guarentee this will never be rolled

one (me) hopes that we can rollout over time, and make progress on a
better network.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 3 Jan 2017 15:20:50 +0000

Hi!

I don’t think there’s anything to be done, besides the guidance already in the draft about path preference: prefer Valid paths.  If the validity state changes later, then it becomes a local policy to use or not.

Alvaro.

On 1/2/17, 8:37 PM, "Randy Bush" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 3 Jan 2017 16:24:58 +0100

Agreed. I guess you could in addition be very clear that a router that once negotiated (and/or send) BGPsec (attributes) should not be expected to always do so. This is implicitly said already, so please decide on your own if you’d like to add anymore text.

Thanks!
Mirja

> Am 03.01.2017 um 16:20 schrieb Alvaro Retana (aretana) <[email-masked]>:
> 
> Hi!
>  
>> On 1/2/17, 8:37 PM, "Randy Bush" <[email-masked]> wrote:
>>

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 3 Jan 2017 15:41:53 +0000

Hi Mirja,

>But as we are talking about this, could there be a similar case here, where a router is known to support BGPsec and others would ignore/drop non-signed announcements? (Sorry if that’s all discussed…

In BGPsec peering session, it is allowed to send signed updates for some prefixes and 
unsigned updates for other prefixes. This is necessary for backward compatibility
and incremental deployment. 

In this scenario,

AS1-----BGP(unsigned)-----------------AS3---------------BGPsec(signed)--------AS4 
                                                                  |
AS2----BGPsec(signed)--------------------

AS3 forwards to AS4 unsigned updates originated from AS1 
and also forwards signed updates originated from AS2.

Just because an AS is known to support BGPsec, it is not required that it must 
send only signed updates. 
On the receive side, it would be purely a matter of local policy to prefer a signed update 
over an unsigned update for the same prefix or how to treat an unsigned update
in path selection process, etc.   

Excerpt from Section 4.1 in the BGPsec protocol draft:
 
   If a BGPsec router has received only a non-BGPsec update message
   containing the AS_PATH attribute (instead of the BGPsec_Path
   attribute) from a peer for a given prefix, then it MUST NOT attach a
   BGPsec_Path attribute when it propagates the update message.  
   ........

   Conversely, if a BGPsec router has received a BGPsec update message
   (with the BGPsec_Path attribute) from a peer for a given prefix and
   it chooses to propagate that peer's route for the prefix, then it
   SHOULD propagate the route as a BGPsec update message containing the
   BGPsec_Path attribute.

Does this answer your question?

Thanks.

Sriram

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 3 Jan 2017 16:11:47 +0000

Hi Peter,

>yup, I think this was part of the original thought process for bgpsec.

A BGP speaker always has the option to drop a BGPsec session,
and send a new BGP open request without the BGPsec capability
(Section 2.2 in the protocol spec document). 
Please also see my response to Mirja.

Thank you.

Sriram

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Jan 2017 08:31:31 +0900

> back will kill the baby and will guarentee this will never be rolled

what do you mean by "no path to go back" and "rolling back?"

where do you see "destroying" your AS?

my only guess is that
  o you have not read the spec or any documentation on it, and
  o you triggered on the phrase "path stripping"

fwiw, path stripping is removing the bgpsec gorp from a bgpsec path and
rendering a classic bgp4 path to hand to a bgp listener who does not
understand bgpsec.  no ASs are harmed in the process.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 04 Jan 2017 12:01:53 +0900

> Agreed. I guess you could in addition be very clear that a router that
> once negotiated (and/or send) BGPsec (attributes) should not be
> expected to always do so.

whoops!  that'll be in -14.  thanks.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 4 Jan 2017 11:40:34 -0500

> what do you mean by "no path to go back" and "rolling back?"
perhaps to paraphrase peter's question/comment: He's worried that the
proposed standard may leave a user of the technology in a position where
'old bgp' is not functioning for him.

I believe we ran over this horse several times in the WG and other places,
basically to provide a path from 'today' to 'tomorrow' the ability to
co-exist is required. On day-0 no bgpsec exists, on day-1 you (peter) turn
up your first bgpsec peer  pop champagne and rejoice... On day-2 you turn
up 200 more... then on day-10 you realize things are not working so you
disable bgpsec via some knob on your vendors' devices...

All along both 'old bgp' and 'new bgpsec bgp' are working alongside each
other. Randy's correct that the protocol / etc specs cover this sort of
thing... fairly well.

Because 'there are no flag days' on the intertubes, we have to plan for
co-existence... Just like ipv6 did... wait, I mean dnssec. ;)

-chris