mailing list archives
Re: So -- what did happen to Panix?
From: bmanning () vacation karoshi com
Date: Fri, 27 Jan 2006 16:12:05 +0000
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
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:
220.127.116.11/24 thinks that AS 4555 is the correct origin
AS 4555 thinks that it should (and does) originate prefix 18.104.22.168/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 22.214.171.124/16 -BUT- never tells
AS 4555 about this and has no direct means to deliver packets
to AS 4555.
Or... we see 126.96.36.199/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
path validation is (again imho) a severable problem the prefix/as