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

["Sriram, Kotikalapudi" <[e-mail]>]

>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.

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 
>negate the potential benefit), we should explain why.

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