Subject: [sidr] comments on BGPsec drafts

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 4 Apr 2011 00:18:03 +0000

Providing some comments on the drafts as a whole.

BGPsec Protocol spec - 
Section 4 requires that each update contain only one NLRI. While you explained in the presentation why this is, it is not adequately
explained in the draft. Since this is a significant change, and is currently based on a technical limitation, please explain it
here.

As stated at the mic, please consider a second (or third) state of validation - expired. It may be that different policy should be
applied in these cases vs. known invalid.

BGP Sec Overview - 
3.2 talks about the recursive nature of the validation. It is probably worth noting that this is going to have at least some impact
on convergence times - long AS paths may take longer to validate than shorter ones, for example, where this isn't really variable
today. This may be an issue depending on how the validation is implemented and the order the updates come in, especially if you
parallelize the processing of updates (that is, the router is still chewing on validation of one update while the next one is being
processed on a different core) - it can cause route churn as one route is preferred and then discarded to pick up another, etc. This
churn is a known issue on initial convergence, but there is often machinery in routers to allow for prioritization of certain
prefixes, certain prefix lengths, etc to limit its effects. I am mainly saying that you should consider the implications of this.
Worth discussing if it's even an option to consider parallelization of validation *within* a given update (feed one AS signature to
each core so that you're processing multiples at once, for example) - I know we're not at the design optimization phase yet, but if
there's a technical reason why this isn't possible or isn't recommended, might be worth making it clear.

4.3 - use case : while I understand we're talking about dumping AS-sets, I think that replace-AS to eliminate private AS is a valid
use case that has to be supported by this implementation. It may be that we have to assume that the AS that is serving as the
replacement is also serving as the originator and signing on behalf of the upstream private ASN, but that should be explicitly
documented if that's what we're aiming for.

Operational considerations - 
As I and others stated at the mic, while we're not expecting formal estimates of something that is in a pre-optimization stage of
design, rough orders of magnitude in terms of the impact to processing and convergence time, CPU, and RIB memory are all things that
would be extremely helpful in evaluating this. Assuming a certain crypto algorithm, what would the expected size of a single update
be when compared with today, for example? Since we're not packing, the research that has been done to show that packing isn't that
important should be directly referenced here, etc.
We know that the design team considered scale and convergence as a top priority, but that's not well-covered in the current drafts.

Security considerations - the same issues as origin validation has with existing routing policy (local pref, for example) being able
to create a situation where an invalid route is preferred over a valid one should be either discussed here or referenced from the
other document.
Thanks, 
Wes 
_________________________________ 
Wesley George 
Sprint 
Core Network Engineering - IP 
O: 703-592-4847   M:703-864-4902 
http://www.sprint.net 
Please note new office phone#
This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by
others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.