Hello Tony,
> Hopefully I've characterized things reasonably
Sincere apologies for critics, but observing this space as well as
hearing voices of operators from all over the world IMHO you have not
even stated the basic preludium to the problem at stake.
I think Russ is not just flaming that this is complex. The way I read
what Russ is not afraid to say is that solutions in place are just not
addressing the real BGP security issue.
If they would we do know (with around for most of us 20 years of
internet deployments behind our belts) how to educate community to
deploy globally any new useful functionality.
However the current proposal may very well address the Internet control
issue rather then real internet security issue and this is the problem.
This is something that non of the authors or implementors will ever
admit is the objective here for a very obvious legal reasons.
Best,
R.
As that old draft's author/editor (started as editor, ended up more
as author, with suggestions), perhaps I can add some clarification to
some of what's being re-hashed here. It's likely many already
understand it; some don't; some could be aided by different wording.
Steve Kent takes the approach that working through the processing
and propagation of updates and securing those operations to the
spec. The notion appears to me to be to model behavior based on
discrete events and the BGP FSM.
Russ White takes the approach that the overall deployed system is
very complex containing many dimensions of variability including but
not limited to time, topology, and local practice/policy. Following
from that is a concern that, beyond a point, adding the additional
complexity being proposed results in either no benefit or negative
impact to the goals of the global routing system.
Hopefully I've characterized things reasonably and this might help
anyone who's having trouble following at home.
Tony
On Thu, Nov 17, 2011 at 7:19 PM, Geoff Huston<[email protected]> wrote:
On 17/11/2011, at 5:10 PM, Randy Bush wrote:
The process SIDR has used is backwards --choose a solution,
then build the requirements around that solution.
the bgpsec requirements document was started from the 2008
document draft-ietf-rpsec-bgpsecrec-10
That document never managed to reconcile the various views relating
to AS Path validation, so I'm unclear if you are citing this as a
completed activity, because to me it certainly appeared to be an
incomplete piece of work.
To be specific to quote from section 7 of this draft:
AS_PATH Feasibility Check: The AS_PATH list may correspond to a
valid list of autonomous systems according to the first
verification category listed in the "Areas to Secure" Section
above. Further study will determine the extent to which this is a
security requirement.
_______________________________________________ sidr mailing list
[email protected] https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________ sidr mailing list
[email protected] https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
