Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11

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

>In practice, what will happen very soon is that there will be a
>BGPsec core with non-BGPsec leaves and branches.

That is a possibility. To encourage leaves (stub ASes) to get on board with BGPsec, the specification 
allows for BGPsec capability to be negotiated independently in each direction (send and receive).
This means that a stub AS can negotiate with its upstream to send signed updates (to the upstream) 
but receive only unsigned updates (i.e. trusts its upstream).
Thus it avoids processing and memory costs associated with processing signed updates and storing them. 
This facilitates the stub AS to avoid expensive HW upgrade, but still benefit from BGPsec.
Please see Section 2 of the BGPsec specification. Also see Sections 6.5 and 6.6 in the 
BGPSEC design discussion document:
http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-07#page-21 

>Sure. But what if one of those BGPsec-capable ASes has a customer that doesn't
>run BGPsec? So:
>
>5+ 4+ 3+ 2+ 1-
>
>(where + is BGPsec and - is no BGPsec)
>
>In this case the entire path will be unprotected, even though four of the five
>ASes in the path are capable of using BGPsec. I fair argument can be made that
>if it's only the origin AS that's non-BGPsec, the protection afforded is very nearly
>as good as in the case where the complete path is BGPsec-protected.
>

Steve Kent summed it up nicely (in his most recent post on the SIDR list) about the pitfalls 
of allowing partial path signing. 
In your specific example above, let us say, there is also an 8+ who is *malicious* and a BGPsec neighbor of 5+.
8+ does not peer with 1-, but nevertheless sends an update with the following malicious AS path to 5+:

8+ 1-  (for the same NLRI as in your example above)

8+ is basically faking that it got an unsigned update from 1- and 
it is forwarding the same to 5+ with a signature (i.e. 8+ signing to 5+).
How will 5+ know that the partially signed update with AS path of {4+ 3+ 2+ 1-} is legitimate 
and that the other partially signed update with AS path {8+ 1-} is malicious? 
It has no way of knowing that.

Sriram