Subject: Re: [RPSEC] BGP Requirements Draft

From: Sandy Murphy <[email-masked]>
Date: Mon, 26 Sep 2005 08:50:20 -0400 (EDT)

>The added AS's are ones that are already there (and only on
>immediately adjacent hops).

Actually, I don't think this is a complete list.  I think that Paul
is talking about the practice (mentioned in other places, including
by you), of putting some far off AS's AS in the path so that AS will
drop the route as constituting a loop - as a way to deny access to your
addresses to some malfeasant or to craft traffic flow.

--Sandy

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

---

From: Blaine Christian <[email-masked]>
Date: Mon, 26 Sep 2005 08:59:39 -0400

> addresses to some malfeasant or to craft traffic flow.

I remember that one...  But, to me all that does is make prefixes  
unreachable by the AS who you are trying to prevent from receiving  
your prefixes.  It is not clear how many operators were actually  
using this method.  I have only had one mention that they were even  
thinking about it.  Perhaps someone can provide an example of an  
operator who does this in production?

---

From: Stefan Mink <[email-masked]>
Date: Mon, 26 Sep 2005 21:00:25 +0200

Hi Christian,

Blaine Christian wrote:
> unreachable by the AS who you are trying to prevent from receiving your 
> prefixes. 

an important detail: it makes exactly _this route_ to the destination
unusable for the included remote AS.
There may be other instances where the remote AS is not added to the
path. By doing this, traffic can only follow the second version,
but not the first. Of course the applicability is limited, i.e. only
one instance of the route (usually the shorter one) makes it through
other ASes.

> It is not clear how many operators were actually using this 
> method.  I have only had one mention that they were even thinking about 
> it.  Perhaps someone can provide an example of an operator who does this 
> in production?

I don't think it's common practise. Maybe we should do a polling
on nanog...

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