North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: So -- what did happen to Panix?
On Fri, Jan 27, 2006 at 10:42:11AM -0500, Joe Abley wrote: > > On 27-Jan-2006, at 07:51, [email protected] 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
|