So -- what did happen to Panix?

Fri Jan 27 16:12:05 UTC 2006

On Fri, Jan 27, 2006 at 10:42:11AM -0500, Joe Abley wrote:
> 
> On 27-Jan-2006, at 07:51, bmanning at 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