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

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

>However, we're aware of people who do this to deny routes to other ASes.
>This means they put someone else's AS in there.

I have heard of this, and Blaine just mentioned this.  But I don't
understand -- why choose this technique to deny routes to other AS's.
It seems to me that a withdrawal or not issuing an update at all
accomplishes the same purpose.

So why is this chosen as the mechanism for denying routes to other AS's?

If there's a unique advantage to doing it this way, that's one thing.

But if this one case is the sticking point behind avoiding a definition
that says you shouldn't insert *ARBITRARY* (note well: ARBITRARY, not
your own) AS's, and if there are other ways to accomplish the same
purpose, then I'd say one alternative would be to prohibit the
behavior and let the operators use the other techniques for accomplishing
their purpose.

--Sandy

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

---

From: Blaine Christian <[email-masked]>
Date: Mon, 24 Jan 2005 14:49:40 -0500

> So why is this chosen as the mechanism for denying routes to other AS's?

The trick is that it works for one specific AS and not the Internet in
general.  If I insert provider Xs AS in the AS path they will reject the
announcement.  No one else will reject it.

I don't know of another knob that can do this...

---

From: Stefan Mink <[email-masked]>
Date: Mon, 24 Jan 2005 20:54:55 +0100

>behavior and let the operators use the other techniques for accomplishing

welcome back to the authorization problem :)
There is currently no clean way to influence the distribution of a route 
once
it left your router...

   tschuess
             Stefan
-- 
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:36:57 -0500

To make this a little more clear for Sandy:

> I don't know of another knob that can do this...

More importantly, you can't deny someone a route transitively without
doing something like this.

To whit:

A ---- B ---- C ---- D ---- E

AS A originates a route.  B doesn't wish AS E to use this route.  There
is no way to "de-authorize" E.  However, if I advertise my route to C
thus, e.g.:

10/8 <B E A>

Despite the fact that the route should have <B A> as an AS_PATH, this
doesn't "break" BGP (although it isn't strictly compliant behavior)
and E will in fact discard the route when it advertised by D->E
because of the loop condition.

The reasons for doing this are many and varied.  They complicate our
life if we're trying to use the AS_PATH adjacencies for security 
purposes.

Also, we could advertise it as:

10/8 <B> [E] <A> (where [] represents a set and <> represents a sequence)

When sets are involved, how do we determine adjancencies?  Compliant
implementations may generate an arbitrary mix of sets and sequences
upon normal aggregation.  When not aggregating along the path, a
set should never be present, so this _should_ limit us to sequences
for most checks.

The questions are thus:
1. Do we wish to accomodate this technique in our security infrastructure?
2. If so, how?  This is probably solution-specific.

-- 
Jeff Haas 
NextHop Technologies