Subject: [RPSEC] issue: operator use

From: Sandy Murphy <[email-masked]>
Date: Tue, 8 Mar 2005 13:56:49 -0500 (EST)

There has been discussion of the need to consider common operator uses
(that are not part of the BGP spec) in the requirements.  There's also
been discussion of the impossibility of analyzing unspecified uses.  I
tried to start a discussion of the common operator uses that would be
considered, but no one picked up on that thread.

First question:  is this an action for the wg?   If people think it
is not needed, ignore the following.

Here's the list again.  The idea is to assemble a list of
operator uses that should not be prevented by the security
requirements draft.  The action is to decide whether each
use is common enough, valuable enough, and safe enough to be
protected from interference from security solutions.

prepending your own AS multiple times on the AS_PATH
   (actually, this is in the base spec, so it's not really an outside
    the spec behavior, but included in the list to reassure people)
prepending/inserting some AS *OTHER THAN YOUR OWN* in the AS_PATH
   (Blaine said he got back few comments from his query to NANOG
   about this, so maybe it is OBE)
deleting private AS's from the AS_PATH 
   (recognizing that some regard this not as a common operator use
   but a required operator use - at least before advertising to the
   general Internet)
not deleting private AS's from the AS_PATH
   (some call this leakage)
deleting non-private AS's from the AS_PATH
   (not talking aggregation and re-origining - this is deleting some AS's
   from the AS_PATH)
proxy aggregation
   (that is, you haven't been allocated the prefix you advertise,
   but you have received prefixes that are covered by the advertised
   prefix)

Note also: I do not intend to imply that the fact that someone,
somewhere, has used bgp fields in a particular way will guarantee
that that usage will be incorporated into the security requirements.
Other factors must also be considered, like the potential for harm if
the use comes from the wrong hands, the difficulty of designing a
security protection that allowed that particular behavior, the
existence of other ways to accomplish the same effect, the prevalence
of the behavior, etc.

--Sandy

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Mar 2005 14:58:27 -0500

>     the spec behavior, but included in the list to reassure people)

right, the BGP spec already addresses this, so it should be explicitly OK

>    about this, so maybe it is OBE)

hopefully this is something we can say is NOT OK

>    but a required operator use - at least before advertising to the

what are the assumptions about private ASes, and what document states 
the assumptions? based on the terminology, I'd expect that these ASes 
ought not appear in advertisements in the public Internet.

>not deleting private AS's from the AS_PATH

see comments above.

>    (not talking aggregation and re-origining - this is deleting some AS's

we need to get an explanation on when this occurs and why it is 
considered appropriate behavior, since it is not consistent with 
comments in the BGP RFC.

>    but you have received prefixes that are covered by the advertised

If the AS performing proxy aggregation is authorized to do so by the 
prefix holders, then it would seem to be OK.  if not, then it becomes 
indistinguishable from bogus origination of prefixes, in general.

Steve

---

From: Blaine Christian <[email-masked]>
Date: Tue, 08 Mar 2005 15:46:06 -0500

I am sure I will have much more to say on the recent threads...  However,
one thought is important to express.  Comment inline...

> hopefully this is something we can say is NOT OK

The one, very notable, exception is the prepending of your external peers AS
number on a "received" advertisement.  Many operators use this, including
me.  This is used to depref/pref advertisements from various peers.

The one mechanism that does not seem to be much used, but was raised by an
operator, was the insertion of a distant AS's AS number in order to ensure
that AS does not process a prefix advertisement.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Mar 2005 16:45:57 -0500

>me.  This is used to depref/pref advertisements from various peers.

so the notion is that you may or may not add one or more instances of 
the peer's AS to bias your choice of route. do you send it with these 
added AS numbers, or just use it internally? if the latter, no 
problem, but the former is an attack, generically. can't you achieve 
the same effect, when sending the advertisement to neighbors, by 
prepending your own AS number several times.

>that AS does not process a prefix advertisement.

Yes, that works, but to paraphrase a famous line from the Watergate 
hearings, "we could do it but it would be wrong."

Steve

---

From: Blaine Christian <[email-masked]>
Date: Tue, 08 Mar 2005 17:18:50 -0500

> prepending your own AS number several times.

Folks could prepend and then deprepend...  I am not sure that is desired
though.  I can count off a few scenarios that would break folks existing
setups.  I think we are going to have to allow folks to prepend their peers
incoming advertisements.  I received significant feedback on this (about a
third) of the community that responded to my request for info.

It is really not an attack if you think about it.  It is just managing my
traffic.  IMHO each "cluster" of like AS numbers should be considered to be
one instance of an AS for the purposes of security.  This seems to be a
reasonable assumption to make.

Regards,

Blaine

---

From: Joe Provo <[email-masked]>
Date: Tue, 8 Mar 2005 17:59:54 -0500

On Tue, Mar 08, 2005 at 01:56:49PM -0500, Sandy Murphy wrote:
> There has been discussion of the need to consider common 
> operator uses (that are not part of the BGP spec) in the 
> requirements.  
[snip]
It will be of interest to see what level of use or specific
applications is considered 'common' or 'abuse of existing 
ambiguities' vs 'use of available resources', and by what 
constituencies.

> prepending your own AS multiple times on the AS_PATH
irrelevant for this purpose as it is part of the spec and 
manipulating your 'own' data.

>    about this, so maybe it is OBE)
this is forgery, generally filtered as part of belts-and-suspenders 
for customer-leak-prevention, and not 'common' in my experience. It
was observed before providers provided customers with remote path
manipulation communities (prepend, supress). remote-action communities
have overtaken path forgery in the past few years.

> not deleting private AS's from the AS_PATH
Dropping the announcement (or stripping in the case of direct 
customers and announcing under your own ASN) is BCP and a 'common' 
interpretation of rfc1930 section 10.  Propaagating these ASNs is 
clearly inappropriate.

>    (not talking aggregation and re-origining - this is deleting 
>    some AS's from the AS_PATH)
Reductive forgery is still forgery.  the only corner case is where
ones own as is the element being remove, a la transparent acting 
route servers.   The current practice appears to be against this
[the self-deleting-entity's neghbor's inability to appropriately 
handle security events has been cited].  Are there route servers 
in operation which currently do this?

> proxy aggregation
>    (that is, you haven't been allocated the prefix you 
>    advertise, but you have received prefixes that are covered 
>    by the advertised prefix)
as long as the atomic-aggregate flag is set, this is not only
within spec but specifically in the design. without atomic-aggregate
set, such path manipulation would be a form of forgery, no?

Cheers,

Joe

-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

---

From: Joe Provo <[email-masked]>
Date: Tue, 8 Mar 2005 18:14:29 -0500

On Tue, Mar 08, 2005 at 05:18:50PM -0500, Blaine Christian wrote:
> 
> [email-masked] wrote:
> > so the notion is that you may or may not add one or more 
> > instances of the peer's AS to bias your choice of route. 
> > do you send it with these added AS numbers, or just use 
> > it internally? if the latter, no problem, but the former 
> > is an attack, generically. can't you achieve the same 
> > effect, when sending the advertisement to neighbors, by
> Folks could prepend and then deprepend...  I am not sure 
> that is desired though.  I can count off a few scenarios 
> that would break folks existing setups.  I think we are 
> going to have to allow folks to prepend their peers 
> incoming advertisements.  I received significant feedback 
> on this (about a third) of the community that responded 
> to my request for info.
> 
> It is really not an attack if you think about it.  It is 
> just managing my traffic.  IMHO each "cluster" of like AS 
> numbers should be considered to be one instance of an AS 
> for the purposes of security.  This seems to be a reasonable 
> assumption to make.

I believe Steve K was driving toward the point that there 
is a large difference between twddling data for internal 
purposes and then propagating those twiddles.  There's no 
detail in the path to indicate which side of the relationship 
adjusted the as-path, and the general assumption is not forgery
and that one prepends one's own data rather than manipulating 
others'.  

In the instances of which you speak, is the peer aware of 
propagating the altered paths? I would imagine if it was 
purely a case of traffic management at a specific point in
the decision tree, then it wouldn't be a problem to not 
propagate those altered paths, no?

I too have to rewind and catch up on the previous messages
(an effective subject line caught my attention) to see if  
some more subtle bits of forgery caught in the wild have 
already been brought up.

Cheers!

Joe

---

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Mar 2005 18:15:59 -0500

>reasonable assumption to make.

I know that this is used legitimately as a traffic engineering 
mechanism. However, this represents a modification of the AS path in 
a fashion that is not consistent with the BGP RFC. Also, since you 
can achieve the same traffic engineering effect by prepending your 
own AS number multiple times, it seems undesirable to make provisions 
to achieve the effect the other way. Moreover, an operator examining 
the path further along would probably interpret the multiple 
instances of your neighbor's AS # as an act by that neighbor to bias 
routing, not an act by you. So, if we were to declare this as an 
acceptable behavior, we are adding ambiguity to path interpretation, 
which is not conducive to security.

Steve

---

From: Blaine Christian <[email-masked]>
Date: Wed, 09 Mar 2005 08:17:25 -0500

> which is not conducive to security.

This is where we have to cite it as an operational issue.  Many folks
prepend inbound advertisements with their peers AS and advertise to the
world.  It is okay to say it is not to be used but we would then have to
provide a means for folks to easily substitute another mechanism.
Typically, I would tell the vendor that it is their software that is going
to break me so they need to come up with a solution that does not.

I am not sure I understand you on the BGP RFC part.  I could not find a spot
in the existing RFC that allows, or disallows, any prepending other than one
prepend on advertisement to an external peer.  Can you tell me what section
refers to this?  Funny enough...  I did find a section in 1771 that refers
to the removal of all duplicate AS' within an AS set.

" If as a result of the above procedure a given AS number appears
      more than once within the aggregated AS_PATH attribute, all, but
      the last instance (rightmost occurrence) of that AS number should
      be removed from the aggregated AS_PATH attribute."

The above text seems to indicate that the authors had the same idea as me
(or I had the same idea as them).  That all instances of a single AS (in our
case adjacent to each other in the path) can be considered one AS for the
purposes of path aggregation (in our case securing the path).

I did also find this text (that you may be referring to)....

" When a given BGP speaker advertises the route to another BGP
      speaker located in its own autonomous system, the advertising
      speaker shall not modify the AS_PATH attribute associated with the
      route."

It may be cutting a fine line but this text does not seem to preclude the
modification of advertisements you receive from your external peers.

There will probably be a lot of fight on the ability to prepend inbound and
outbound.  I think we need to have a good story on this otherwise we will
spend all our time defending the position that you are not allowed to
prepend your peers AS on a received advertisement.

Can we approach this from a different angle?  What security problems would
result in grouping AS's that are adjacent duplicates?  It does not seem like
it would be a hard problem to solve.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 9 Mar 2005 08:51:50 -0500

On Wed, Mar 09, 2005 at 08:17:25AM -0500, Blaine Christian wrote:
> prepend on advertisement to an external peer.

Let's use draft-ietf-idr-bgp4-26.txt as that's the one that's about to RFC.
This allows one to prepend multiple instances of one's AS number.

It doesn't talk about prepending one's neighbor's AS number.

> Can you tell me what section

This makes sense in both the RFC 1771 and -26 contexts.  A set is a set
and duplicate elements add no meaning.  (Unfortunately,) common usage
lead to the AS_SETs adding one to the calculated length of
the AS_PATH.  Thus, the entire set counts as one rather than one per
each AS in the set.

> modification of advertisements you receive from your external peers.

This is the usual argument over whether or not "that which is not said
is prohibited" is what is usually meant.  In more cases than not, this
is a reasonable way to read a specification.

The property you're trying to take advantage of is artificially lengthening
the AS_PATH received from a peer in order to bias the preference of the
route within your AS using the BGP route selection rules.  This technique
is very effective and achieves things that aren't easily achieved using
other policy.  However, it does have negative effects upon the party that
sent you the route since if this artificially lengthened route is used
and propagated, it'll bias route selection throughout the Internet.

As far as the loop prevention properties of the AS_PATH goes, artificially
lengthening the AS_PATH doesn't really break anything.  As far as the
security implications of adjacent ASes in the AS_PATH, it doesn't change
anything.  However, any mechanism we're likely to propose with regards
to preventing modification of the AS_PATH outside of the stated rules
of the RFCs would cause the artificial lengthening to generate potentially
invalid routes.  (I.e. you've modified a bit of the route you shouldn't.)

> outbound.

Only on inbound, I think.  It wouldn't shock me if someone introduced 
a mechanism that allows for biasing routes at a particular portion of
the route selection process.  I believe John Scudder had suggested
something along these lines, although the mechanism was very broad.

> it would be a hard problem to solve.

As mentioned above, at least one security implication is you are
(negatively) biasing downstream route selection using the neighbor
AS rather than your own AS.

-- 
Jeff Haas 
NextHop Technologies

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Mar 2005 10:45:02 -0500

>to break me so they need to come up with a solution that does not.

from the RV data I have seen, and based on discussions with at least 
one ISP, prepending your own AS number is supported by routers, and 
that's why I suggest it is a viable alternative.

>to the removal of all duplicate AS' within an AS set.

RFC 1771 does not allow prepending of multiple instances of an SA, 
but the latest BGP draft, which is in the RFC editor's queue, does. 
Section 5.1.2 of the document says:

    Whenever the modification of the AS_PATH attribute calls for 
including or prepending the AS number of the local system, the local 
system MAY include/prepend more than one instance of its own AS 
number in the AS_PATH attribute. This is controlled via local 
configuration.

Appendix A, which describes changes from 1771, says:

The ability of a BGP speaker to include more than one instance of its 
own AS in the AS_PATH attribute for the purpose of inter-AS
traffic engineering.

So, the change allows an AS to append its OWN AS number multiple 
times, and the rationale is that this is allowed for traffic 
engineering purposes.

>purposes of path aggregation (in our case securing the path).

this text applies to aggregation, but not to normal, non-aggregation, 
processing.  so, I don't think it conflicts with the text I cited 
above.

>modification of advertisements you receive from your external peers.

I would not draw the same conclusion.

>prepend your peers AS on a received advertisement.

the latest version of the spec explicitly allows prepending your own 
AS, and does not say anything about changing the AS path received 
from a neighbor in the fashion you describe. we seem to be having an 
argument over whether one should bias a route by adding one's own AS 
multiple times, (which is explicitly allowed now) vs. adding the 
preceding peer's AS number multiple times. both approaches achieve 
the same effect, when advertised to other ASes, and the method 
approved in the new spec makes it clear which AS is trying to impose 
the bias. if we allow both, then later ASes can't tell which of two 
neighboring ASes did the biasing, which seems inappropriate.

>it would be a hard problem to solve.

I see two problems:
	- this is an example of adding someone else's AS to a path, 
which is generally something we agree is a no-no, and thus requires a 
special case exception to allow such "tampering."
	- as noted above, if we allow both forms of multi-AS 
prepending, we create ambiguity for other ASes, since they can't know 
which AS is trying to bias the route.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 10 Mar 2005 13:41:33 -0500 (Eastern Standard Time)

>> There will probably be a lot of fight on the ability to prepend inbound 
>> and outbound.
>
> Only on inbound, I think.  It wouldn't shock me if someone introduced a 
> mechanism that allows for biasing routes at a particular portion of the 
> route selection process.  I believe John Scudder had suggested something 
> along these lines, although the mechanism was very broad.

I don't think I know of anyone prepending inbound and then propagating the 
routes thus prepended.... (?) I know it might exist someplace, but I just 
don't know of any given case.

The problem is, you don't know, from outside the AS, if the prepend was 
inbound or outbound, I think. For instance, Cisco now allows the prepending 
of your peer's as onto the path on the outbound side of your AS. For 
instance:

A---B---C

B can actually prepend A at it's border with C. There's a simple customer 
demand for this--A doesn't want to impact B's selection, or B's customers, 
but wants to impact the selection process beyond B. This is a slight 
variant of advertising your more specifics to B with NO_EXPORT, and your 
aggregate to B with no communities at all....

Anyway C can't tell if A or B actually did the prepending, and I don't know 
that C should or wants to care (?).

> AS rather than your own AS.

But, that's the point Blaine's making--AS' that prepend are engineering the 
traffic flows on their inbound links. The problem we're running in to here 
is that we have to decide is engineering traffic is actually an attack or 
not. I suppose it could be in some circumstances, but it's not going to be 
in others, and it's going to be hard to tell the difference between the 
two, when all the players involved are legitimate.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Mar 2005 13:50:05 -0500

> don't know of any given case.

Ask around.  If I'm getting asked to support it, someone else is already
doing it. :-)

> inbound or outbound, I think.

100% agreed.  It's also not a problem from either a loop prevention
basis nor a problem with checking AS adjacencies when no cryptographic
mechanisms are using on the actual AS_PATH path attribute.  If
the actual AS_PATH is cryptographically signed in a stacked fashion,
then we have a possible issue.

Then again, giving it 10 seconds of thought, it's only a *possible*
issue.

Consider a theoretical signing mechanism where we have AS adjacencies
A B C.  If A advertises A A and B prepends on ingress A A but only
advertises B, then you'll get A A A A B at C.

The signature stack would look something roughly like:
(A A (A A B))

So long as one can distinguish that B added the other A's, we
could certainly permit this sort of thing when it doesn't break
the adjacencies.  (I.e. this doesn't break routing, and there's a
way we could make this work if we wanted to.)

> traffic flows on their inbound links.

That's 1/2 of it.  Prepending on egress engineers on incoming
traffic.  Prepending on ingress engineers on route selection within
the AS and will further bias incoming traffic.

> The problem we're running in to here 

I'd agree.

-- 
Jeff Haas 
NextHop Technologies

---

From: Stefan Mink <[email-masked]>
Date: Thu, 17 Mar 2005 23:33:07 +0100

Hi Steve,

Stephen Kent wrote:
> mechanism. However, this represents a modification of the AS path in a
> fashion that is not consistent with the BGP RFC. Also, since you can
> achieve the same traffic engineering effect by prepending your own AS
> number multiple times, it seems undesirable to make provisions to
> achieve the effect the other way.

<operator>
that's not true although it might be a vendor specific issue:

if you prepend a received route with your own AS and advertise
it over an IBGP session, at least juniper routers discard the
route because the detect the local as in the path. This is not
the case with cisco routers which happily accept such routes on
IBGP sessions.

I never bothered to check who's right and who's wrong but in
any case this is the reason why I - running a dual vendor network -
HAVE to prepend with the AS of the peer and not with my own AS.
</operator>

    tschuess
              Stefan

PS: I know there is a knob on JUNOS so you can permit the local
AS in received routes but this is AFAIK a global option and by
thus would also concern EBGP sessions. This would mean you would
accept your own routes also over EBGP links.

--
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Stefan Mink <[email-masked]>
Date: Thu, 17 Mar 2005 23:44:43 +0100

Hi Russ,

Russ White wrote:
> But, that's the point Blaine's making--AS' that prepend are engineering
> the traffic flows on their inbound links.

it also concerns local traffic flows and how they leave your
network. This is especially important if you run a content
heavy network. So it's not necessarily inbound TE but definitely
outbound TE

> The problem we're running in
> to here is that we have to decide is engineering traffic is actually an
> attack or not. I suppose it could be in some circumstances, but it's not
> going to be in others, and it's going to be hard to tell the difference
> between the two, when all the players involved are legitimate.

the main problem is, that the knob "local pref", which is meant
to be used for local TE, is just to brutal in the route decision
process, because if you assign a lower locpref to a route, it
wont be used at all as long as there is an alternative with a
regular or higher localpref value.
MED on the other hand is just meant to be used for routes
received from the same AS. So AS-path prepending is sometimes indeed
a resonable way to do TE. People who don't like AS path prependings
tend to use MED independently of the nexthop AS, but this is also
not the way MED is being meant to be used, but it's at least a local
thing and invisible to the rest of the internet.

    tschuess
              Stefan