Subject: Re: [RPSEC] Back to the Basics: The AS Path

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 14:24:55 -0500 (EST)

>> Ouch.  People actually operationally add arbitrary AS's to the AS_PATH?
>
>        every single day.  AS padding is common practice

*ARBITRARY* prepending?  So AS 100 puts AS 333's AS in the AS_PATH it
is advertising?

Note:  I am not now suggesting, nor have I ever suggested, that
prepending your own AS multiple times is a problem.

If one wants to allow *ARBITRARY* AS prepending, then one has a very
difficult time telling a totally bogus AS_PATH from a legitimate,
operational use AS_PATH.

>> Any chance this could be considered a current operational behavior
>> that would be deprecated as faciilitating abusive practices?
>
>        perhaps not. why would you consider this an abusive practice?

I didn't say it was an abusive practice.  I said it facilitated abusive
practices.  By making the totoally fictional bogus AS_PATH indistinguishable
(at least to me right now) from a AS_PATH deliberately created by
a legitimate operator.

--Sandy

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: [email-masked]
Date: Mon, 24 Jan 2005 19:53:02 +0000

> *ARBITRARY* prepending?  So AS 100 puts AS 333's AS in the AS_PATH it

	so if AS 4555 prepended AS 7085 and AS 2886, there would
	be a problem for you? (all these ASN are held by me)

> prepending your own AS multiple times is a problem.

	right.

> (at least to me right now) from a AS_PATH deliberately created by

	ok... so when a process is deliberatly designed to be "opaque"
	to external view/review, it lends itself/facilites potentially
	abusive practices.  can RPSEC deal w/ "opaque" bits in the
	validation path?

---

From: Stefan Mink <[email-masked]>
Date: Mon, 24 Jan 2005 21:19:31 +0100

>be a problem for you? (all these ASN are held by me)

is there are reason why you wanted to prepend the other two ASes
besides wanting to avoid they use the route? If not prepending by
4555 would perfectly do as well, wouln't it?

   tschuess
             Stefan Mink
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Jan 2005 15:39:24 -0500

Bill,

> 	be a problem for you? (all these ASN are held by me)

This would depend on the actual security mechanism being used.
To suggest a mechanism that relies on signing set adjacencies, there
is nothing fundamentally wrong with:

<4555 7085 2666 X> being advertised by 4555 when it was learned from
X, so long as the chain is signed <4555 <7085 <2666 X>>>

Note that this is just meant to illustrate the problem is not
insurmountable, not to make a specific recommendation of how we deal with this
issue.

-- 
Jeff Haas 
NextHop Technologies