On Fri, Jan 27, 2006 at 10:42:11AM -0500, Joe Abley wrote:
On 27-Jan-2006, at 07:51, bmanning@vacation.karoshi.com wrote:
perhaps you mean certified validation of prefix origin and path.
In the absense of path valdiation, a method of determining the real origin of a prefix is also required, if the goal is to prevent intentional hijacking as well as unintentional origination. Simply looking at the right-most entry in the AS_PATH doesn't cut it, since anybody can "set as-path prepend P".
but by definition, the right-most entry is the prefix origin... the question becomes, is that the origin the prefix expects? to use an historical example: 198.32.6.0/24 thinks that AS 4555 is the correct origin AS 4555 thinks that it should (and does) originate prefix 198.32.6.0/24 AS 4555 uses AS 226 and 701 as transit providers. AS 1239 wants to be helpful and tells its peers that it is the proper origin for prefix 198.32.0.0/16 -BUT- never tells AS 4555 about this and has no direct means to deliver packets to AS 4555. Or... we see 128.9.160.0/24 as originating from multiple ASNs. there is no requirement for single AS origin - is that "theft" or an engineering tradeoff?
This suggests to me that either we can't separate origin validation from path validation (which sucks the former into the more difficult problems associated with the latter), or we need a better measure of "origin" (e.g. a PKI and an attribute which carries a signature).
i was just interested in the problem of assertion of origination. it needs to be done w/o a centralized repositiory (imho) because that method has scalability problems. such a technique does open new chances to "confuse" ... e.g. what happens when the prefix is seen from the same apparent AS but w/ two or more different signatures? path validation is (again imho) a severable problem the prefix/as origin.
Joe