Subject: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

From: Chris Morrow <[email-masked]>
Date: Wed, 07 Oct 2015 11:32:06 -0400

Howdy WG folks,
Please consider this your warning/notice that the WGLC has been started for:

  draft-ietf-sidr-bgpsec-overview

Abstract:
  "This document provides an overview of a security extension to the
   Border Gateway Protocol (BGP) referred to as BGPsec.  BGPsec improves
   security for BGP routing."

Please give this a read, send comments if there are any, and let us
know if this is prepared for publication request.

Thanks!

-chris
co-chair

---

From: Sean Turner <[email-masked]>
Date: Wed, 7 Oct 2015 17:24:01 -0400

We’ll need to figure out what to do about the I-D.sidr-as-migration reference it’s in the “IESG Dead” state.

I guess s3.2 is going to match whatever updates are made to bgpsec-protocol-14.

spt

On Oct 07, 2015, at 11:32, Chris Morrow <[email-masked]> wrote:

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

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 8 Oct 2015 05:14:20 -0400

> We’ll need to figure out what to do about the I-D.sidr-as-migration reference it’s in the “IESG Dead” state.

Thanks for the heads up, we’ll investigate with the AD.

—Sandy, speaking as wg co-chair

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 8 Oct 2015 05:45:35 -0400

Speaking as regular ol’ member

> I guess s3.2 is going to match whatever updates are made to bgpsec-protocol-14.

Looking at that section, I think it matches the planned updates to the bgpsec protocol.

Ironically, I think it matches the planned updates more directly than it matches the current state of the bgpsec protocol, depending on how you read the exact wording.

     .  BGPsec_Path contains 3 signatures :
          o  Signature from AS 1 protecting

             192.0.2/24, AS 1 and AS 2

This will still be true in the updates, no problem.

          o  Signature from AS 2 protecting

             Everything AS 1's signature protected, and AS 3

Right now, the bgpsec protocol’s signature from AS 2 covers the signature from AS 1, not “Everything AS 1’s signature protected”.  Of course, by induction, that protects “Everything AS 1’s signature protected”.  So not wrong, just indirectly true.

The intent as I understand it of the updates to the bgpsec protocol are to make the signature from AS 2 cover and directly protect “Everything AS 1’s signature protected”.

IMHO.  You are an author, so…..

—Sandy, speaking as regular ol’ member

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 8 Oct 2015 09:54:25 -0400

> Thanks for the heads up, we’ll investigate with the AD.

The answer from the AD is:

   The system changed it to Dead from "AD is Watching" when the draft expired.

   In any case, all "Dead" means is that the IESG is not tracking the document, not that we're in fact killing it.

—Sandy

---

From: "George, Wes" <[email-masked]>
Date: Fri, 9 Oct 2015 19:36:54 +0000

On 10/8/15, 9:54 AM, "sidr on behalf of Sandra Murphy"
<[email-masked] on behalf of [email-masked]> wrote:

>   In any case, all "Dead" means is that the IESG is not tracking the
>document, not that we're in fact killing it.

Oops. Now that I've (finally) gotten through the multiple significant
revisions necessary on the parent doc in IDR, and it sits in the RFC
editor's queue, I have some cycles to finish this one up. I'll work to get
an update before the posting cutoff for Yokohama, though I'm not sure we
need to discuss it during the meeting to get it moving forward again.
I'll also try to carve some time next before this document's WGLC ends to
review it with the as-migration draft in mind.

Thanks,

Wes

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "George, Wes" <[email-masked]>
Date: Wed, 14 Oct 2015 21:25:34 +0000

Gave this a review, and stumbled across an issue that may not necessarily
be gating to this draft, but should probably be addressed in some other
drafts.

Regarding this text in 4.2:
"Additionally, BGPsec requires that all BGPsec speakers will support
   4-byte AS Numbers [RFC6793]. This is because the co-existence
   strategy for 4-byte AS numbers and legacy 2-byte AS speakers that
   gives special meaning to AS 23456 is incompatible with the security
   the security properties that BGPsec seeks to provide."

Nit: "the security" appears to be duplicated.

Substantive: I had to think through this for a bit to make sure I
understood why this is true beyond the obvious problem of AS23456 not
being unique. I think we need some additional words explaining why, though
I am not sure if it belongs here, in the protocol draft, or in sriram's
design-choices doc (7.6 is very thin on explanation). I think that this is
a specific corner case for the more generic case of incremental
deployment, where a given path has some routers/ASNs that support BGPSec
and some that do not, and as far as I can tell, incremental deployment
isn't really discussed as a concept beyond the [non]negotiation of support
between peers.

When a BGPSec-capable router sends updates to a non-capable peer, it
strips the BGPSEC_Path attribute from any BGPSec-protected routes it is
propagating and announces a regular AS_PATH, and therefore any protection
beyond that point is lost.
Section 4.2 of the protocol doc says that if a BGPSec-capable router
receives updates from a non-BGPSec peer, it will not sign those updates
when propagating them to other BGPSec-capable peers. As a result, that
route's path will not be protected at all. However, I couldn't find that
particular set of interactions discussed in any of the documents in the
context of incremental deployment, and what it can and cannot do to
protect different route announcements.

In other words, BGPSec supports securing the path when:
- All routers end to end support BGPSec, which results in the entire path
being protected.
- The originating router and one or more contiguous routers (ASNs) in the
downstream path support BGPSec, but one or more routers before the route's
final destination do not support it. This results in the BGPSec signatures
being stripped and falling back to insecure mode beyond the last
contiguous BGPSec-capable router, but still provides partial protection
through the portion of the path that is BGPSec-capable. This is true even
when a gap of one or more BGPSec-incapable routers exists in the middle,
followed by additional BGPSec-capable routers, as only the first part will
be secured.

BGPSec does *not* support securing the path even partially when:
- The originating router and one or more routers in the downstream path do
not support BGPSec, but send the update to router(s) that do support
BGPSec.
I.e. There is no model in BGPSec for updates that have [unsigned AS_PATH
of one or more ASNs] + [Signed BGPSec_Path] of one or more additional ASNs
to at least secure the part of the path where BGPSec is supported.
So you can grow BGPSec's chain of protection from origin to "middle" and
gain some incremental benefit across the part of the path that supports
BGPSec, but you cannot grow BGPSec's chain of protection from "middle" to
end and gain the same incremental benefit, even in the case where only the
originating router doesn't support BGPSec but the rest of the path does. I
think I understand the reasons why we chose not to allow this case, but I
don't know that this is discussed anywhere in these terms. There is a
discussion in 6.4 of Sriram's design-choices doc, but I think it's
incomplete since it only discusses it in terms of it being unacceptable to
sign updates that it can't verify. IMO there's a difference between
signing an unsigned update and carrying unsigned updates alongside signed
ones so that it is clear which part of the path is rigorously protected vs
not. Put differently: "I have no idea whether the people before Randy were
telling the truth, but I can assert that Randy, Sandy, Chris, Matt, and
Rob all verifiably told the truth about their part of the path when they
sent the route to me." I think maybe that has some value in an incremental
model, but if it doesn't (or is sufficiently difficult to implement as to
negate the potential benefit), we should explain why.

Thanks,

Wes

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 14 Oct 2015 23:20:42 +0000

>I think that this is a specific corner case for the more generic case of incremental 
>and some that do not, and as far as I can tell, incremental deployment isn't really 
>discussed as a concept beyond the [non]negotiation of support between peers.

We did talk about the concept of BGPsec islands in [draft-sriram-bgpsec-design-choices].

"6.3.2.  Discussion

   During partial deployment, there will be BGPSEC islands as a result
   of this approach to incremental deployment.  Updates that originate
   within a BGPSEC island will generally propagate with signed AS paths
   to the edges of that island."

A natural consequence of the [non]negotiation of support between peers,
is the formation of BGPsec islands. 
That is indeed how incremental deployment would look like.
We should expand on the discussion there to add that as BGPsec adoption grows,
the islands will expand outward (subsuming non-BGPsec portions of the Internet)
and/or pairs of islands may join together to form larger BGPsec islands.   

>There is a discussion in 6.4 of Sriram's design-choices doc, but I think it's incomplete 
>since it only discusses it in terms of it being unacceptable to sign updates that it can't verify.

"unacceptable to sign updates that it can't verify" -- I don't read that in Section 6.4. 

"6.4.1.  Decision

   It was decided that partial path signing in BGPSEC will not be
   allowed.  A BGPSEC update must be fully signed, i.e., each AS in the
   AS-PATH must sign the update.  So in a signed update there must be a
   signature corresponding each AS in the AS path."

>Put differently: "I have no idea whether the people before Randy were 
>telling the truth, but I can assert that Randy, Sandy, Chris, Matt, and Rob 
>all verifiably told the truth about their part of the path when they 
>sent the route to me." I think maybe that has some value in an incremental model, 
>but if it doesn't (or is sufficiently difficult to implement as to 

The AS that you named Randy could be a bad actor,
and may have changed the AS path segment before it 
(dropped some ASes, reduced AS prepends, etc.).
Imagine Rob receives another update for the same NLRI that is completely unsigned,
and it has a path via Wes, Chris, and Jeff.
Let us say both updates pass origin validation. 
Should Rob trust the partially-singed update via Randy, Sandy, Chris, and  Matt,
or should he trust the completely unsigned latter update?
If Rob gives priority to partially-signed path over completely unsigned path,
there is potential for trouble (as in the example above).
Then what is the use of partially signed updates? 
That the was kind of reasoning why the design decision was made not to allow
partially signed paths. This reasoning is outlined in Section 6.4.2 of the 
design choices doc, but certainly the explanation can be further improved.

Thank you.

Sriram

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 15 Oct 2015 07:02:22 -0400

> be gating to this draft, but should probably be addressed in some other

…

> isn't really discussed as a concept beyond the [non]negotiation of support

Do you think the bgpsec-ops draft is the right place for that discussion?

Sriram’s draft is an individual submission, not a wg draft.  Sriram can put text there if he wants.  But it’s not subject to wg consensus.

—Sandy

---

From: "George, Wes" <[email-masked]>
Date: Thu, 15 Oct 2015 14:13:36 +0000

>"unacceptable to sign updates that it can't verify" -- I don't read that

WG] I interpreted it that way based on 6.4.2. More about that below.
>>Rob

WG] I understand that. I think you're missing the distinction I'm making
between the signed and unsigned parts of the update. In this partial-sign
mode, the way I expect it would work to be at all useful is that any
policy based on the trust of signed updates would only apply to the
portion that is signed, not the entire path. I can't see a blanket trust
of a partially signed route as a binary thing such that you could
automatically prefer partial sign over unsigned, and so your attack vector
is overly simplistic. The partial signing only matters if you care about
the actual data that is being protected inside the signed part. I might
not care that I can't explicitly verify that the AS path started at your
house, then went through Joe's Bait Shop and WISP before connecting to
Randy. But I might care that I can explicitly verify that it went from
Randy to Sandy to Chris to Matt without any unplanned excursions through
Alice or Bob.
As I said, the logic starts getting difficult from a route policy
perspective, but I was trying to point out that the existing text seems to
say that a partially signed update (one that originates unsigned and is
later signed from mid-path to end) is somehow implying a level of trust on
the unsigned portion that doesn't exist. I think the reality is that
partially signed updates would require some additional changes in the
protocol to make that useful, and a significant amount of additional logic
to make it work in policy-land, which may not be worth the effort, but
saying that we don't want to protect the BGPSec-capable part of the path
because we can't protect the preceding part of the path that isn't BGPSec
capable seems circular logic to me.

Wes

---

From: "George, Wes" <[email-masked]>
Date: Thu, 15 Oct 2015 14:21:54 +0000

On 10/15/15, 7:02 AM, "Sandra Murphy" <[email-masked]> wrote:

>Sriram’s draft is an individual submission, not a wg draft.

WG] Well, I'm the wrong person to answer that question because I feel like
SIDR is especially bad about making the reader chase things across
multiple drafts in some mistaken attempt to make the individual documents
more concise. I had to go look at 3 or 4 documents (the BGPsec overview
intro references 8) in order to see if there was more info available
discussing this point that was confusing me, and from Sriram's response
it's clear that I missed at least one portion of that discussion in my
cursory search. I have read many of the documents in the past and should
have some familiarity with them that the average reader may not, so I
think this is indicative of a problem with our document organization, and
in how we decide what is relevant enough to be in the primary document vs
being pigeonholed in a separate one.

Sriram is always quite responsive to feedback, so I'm sure he'll address
some of the discussion in his draft. But given that at least this WG
draft, and possibly others are referencing Sriram's draft in lieu of
explaining things like this directly, is there any reason why we shouldn't
just adopt Sriram's draft? It seems to be representing previous consensus
within the WG on a significant number of major protocol design elements,
so the fact that it isn't a consensus document seems odd.

Wes