Re: [RPSEC] BGP Security Requirements v08

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> I do too but if it involves information using a slow, almost static,
>> OOB mechanism such as IRR or X.509 based ROA, then it needs some means
>> of expressing the possible AS adjacencies and the policies applied
>> over those adjacencies.  If so, we're right back to RPSL.  We might as
>> well just pick up that work and use a different underlying delivery if
>> the RPS work was considered unacceptable.

Perhaps we should leave out the actual mechanisms, and just leave the
option for out of band delivery open. :-)

>> Sorry.  Should have said advertisement.

Really, advertisements aren't end-to-end in BGP, either. Any time you're
designing something, and have to start making exceptions to the rule for
each situation brought up, you should probably go back and rethink the
paradigm your using. The AS Path is our favorite "whipping boy," but, in
reality, the AS Path is just one attribute among many in BGP, and, like
other attributes, the AS Path is mutable. So far, we've discovered:

o AS Path Prepend
o AS Path Stripping
o Aggregation
o Local AS

At least that change the processing rules for the AS Path, or change the
AS Path itself. If we think of the AS Path as being constant end to end,
and plan security based on that thinking, then we must think in
exceptions to the rule set for each possible modification to the AS
Path, and as people think of new ways to modify the AS Path, we have to
think of new exceptions to the rules.

It seems, to me, that it's easier just not to think of the AS Path as
anything more, or less, than an attribute among attributes, all mutable
for various reasons. This allows us to stop thinking in terms of an
"end-to-end" advertisement, and see BGP for what it really is: A
distributed database system in which each device along the way might
change the data in subtle or not-so-subtle ways, and for valid reasons.

The question then changes from: "Who has touched this," to: "Is the data
valid?" Of course, then you have to decide what "valid" means, but,
there we digress into a lot of other conversations we've already had,
and I don't want to repeat. :-)

Going back to the original question:

The basic point, to me, is that the validity of the data is not a
"true/false" situation. Hence, it's possible that passing information
through or around a non-implementing AS, whichever way you want to put
it, has potential benefit. There's no way to know that until you
actually look at the way the proposed mechanism works, though.

:-)

Russ

- --
riw@cisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGn2nUER27sUhU9OQRAiXHAJ9l0McWqdsxU3i31TAYp7dornbHCwCgkUfM
jYsrkP9U8AStueMDhXT9GrQ=
=XNRJ
-----END PGP SIGNATURE-----

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec