Brian, I am addressing your new questions (which still are about stub AS and proxy signing) under the new thread.
>It is all fine and well to do origin-validation based on BGP origination, but >since the >current design of bgpsec is anchored to (vanilla, non-sec) BGP origination as >well, >this means identifying affected elements when challenging the bgpsec design. The design of BGPSEC assumes that all participating ASs are BGPSEC capable. The stub AS is assumed (required) at the minimum to be capable of signing the prefix(es) it originates. Vanilla, non-sec stub ASs are not part of BGPSEC islands. They join BGPSEC islands when they make an arrangement with their upstream at least to sign towards them even though they may agree to receive only unsigned updates from their upstream. >And, what I'm suggesting is, that restricting bgpsec deployment to only origin >AS >operators who deploy bgpsec (i.e. excluding proxy injection into bgpsec from >non-bgpsec origins), is not something the operator >community is likely to accept with open arms. If a stub AS operator trusts the upstream transit provider and hands her private key to the upstream AS operator, that cannot be ruled out since it is a private arrangement. But the BGPSEC protocol need not specify the same (i.e., arrangement of proxy injection) as it can always be done by consenting parties. >There are too many edge ASNs today, using too many vendors' equipment >with too many varieties of equipment within vendors, and too varied code base, >to believe rapid uptake or critical mass is feasible >in the timeline the WG participants might like to believe. Interestingly, the same arguments that you use above were used to include support for simplex BGPSEC in the design for accommodating stub ASs (the small, not very resourceful AS operator). Again, quoting from bgpsec-ops document: Section 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. BGPsec protocol capability negotiation provides for a speaker signing the data it sends but being unable to accept signed data. Thus a smallish edge router may hold only its own signing key(s) and sign it's announcement but not receive signed announcements and therefore not need to deal with the majority of the RPKI. As the vast majority (84%) of ASs are stubs, and they announce the majority of prefixes, this allows for simpler and cheaper early incremental deployment. It may also mean that edge sites concerned with routing security will be attracted to upstreams which support BGPsec. Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
