Subject: Re: [RPSEC] issue: operator use

From: Sandy Murphy <[email-masked]>
Date: Wed, 9 Mar 2005 11:36:32 -0500 (EST)

>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.

Jeff, you say "whether or not", so I'm not certain which standpoint
you are saying is a reasonable way to read the spec.

I have heard this stated as "anything not prohibited is permitted".
I am responding to that interpretation.

I don't agree that it is reasonable.  If the spec says "add 1 to the TTL
and send" but does not say "do not add 2, do not subtract 1, do not
change the TTL to 200", I don't think that anyone could justify
adding 2, subtracting 1, etc on that basis of it not being prohibited.

The spec says add you own AS (as many times as you like) to the AS_PATH.
Other things are done and commonly.  I don't think that "the spec doesn't
say you can't" as justification when it explicitly says what you are to
do.

Furthermore.

There are an infinite (well, ok, not infinite, but one heckofa big number)
of behaviors not mentioned in the spec (for TTL example: don't add 2, don't
add 3, ...., don't subtract 1, don't subtract 2,  ...., don't multiply
by 2, don't multiply by 3,.... don't change to 13, don't change to 14,
....)

Trying to define the security for such an interpretation of what the
spec means would be impossible.  Give up now.  Declare failure and
announce the end of the world.  Etc.

I'm pushing here, but the point is important.  Reading specs that
broadly presents real problems in designing security.

The reason such broad interpretations of the spec have not led to
uninteroperability is that no one has been checking the AS_PATH for
compliance.  Even checking the AS_PATH for the peer's AS has not been
done (and that has gone back and forth in idr discussions of the
vulnerabilities, let me tell you), for example.

If we're trying to secure things, we can't necessarily allow any
manipulation that people have been performing.  (The reason why
people are concerned about BGP is that some people have been doing
some rather hurtful manipulations.)  Is it common, is it uniquely
useful, can it be misused, is it secureable - all these have to
be answered.

--Sandy

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

---

From: Guy Tal <[email-masked]>
Date: Wed, 9 Mar 2005 12:08:24 -0500 (EST)

I wanted to chime in on the prepending issue. IMHO, one should
*not* be able to prepend any AS other than the network AS one controls.
It's called an Autonomous System for a reason. Simply put, If you do not
control a router in an AS, you should not be able to add that AS in the
AS_PATH. To add another network's AS that you don't control is similar to
stealing or slander in my book. There are ways to accomplish route
preference other than manipulating AS_PATH.
	On a similar note, I've talked with two customers of GX's that
have built a business model around gathering small customers, aggregating
them, then announcing all those routes sans AS to make it appear for the
customers that they are direct customers of us or anyone else the
middleman AS is connected to. Do these guys need to come up with a new
business model? Or will there be provisions for a model like this?

Guy

---

From: "Stephen J. Wilcox" <[email-masked]>
Date: Wed, 9 Mar 2005 17:28:10 +0000 (GMT)

Hi Guy,
 I dont think the spec is the right place to regulate it tho, there are reasons 
why someone might prepend an asn other than the one the bgp process is running 
under that is not the asn of another company's network

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Mar 2005 09:08:13 -0500

>business model? Or will there be provisions for a model like this?

Guy,

I think an essential part of any BGP security solution will be a 
facility that enables each prefix holder to authorize one or more 
ASes to originate the prefixes of that holder. With such a facility 
in place, it would be OK for your customers to authorize you to 
originate their prefixes. This accommodates the business model you 
described, yet it prevents any AS that the prefix holders did not 
authorized from being able to originate the prefixes, without 
detection. I think this is a reasonable candidate for inclusion in 
the list of requirements.

Steve

---

From: Guy Tal <[email-masked]>
Date: Thu, 10 Mar 2005 11:00:16 -0500 (EST)

> the list of requirements.

Well, the business model I'm describing is a little different than what
you had made a provision for. Let me give a little more detail...

ASN X has a route-server that gets a feed of NLRIs from multiple tier1s.
They allow smaller networks that are colocated in the same building in
which they have facilities to purchase transit to one, two, or all of
those tier1s on a monthly basis. They announce to the smaller networks the
tier1 routes without prepending their AS. (This is not as big of a concern
because this is essentially going to stub networks). They also announce to
the tier1s the routes from the smaller networks, also without prepending
their AS. This is where I had my concern. The rest of the internet sees
these smaller customers as direct customers of whatever tier1 they
purchase transit from. The origin AS is still there, the tier1 is not
originating the route for them. The middleman ASN is the only one that is
not in the path. I feel that this will not jive with as_path security that
is being discussed here. And because this is a service provided for short
amount of times, I'm not sure what kind of administrative hassle it will
be to have to register and unregister routes and ASNs, etc.

I actually am not a fan of this model, but since it's out there, if what
we're working on here will break it, I'd like to let those networks know
that its coming down the pipe when something more concrete comes out.

Guy

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Mar 2005 22:30:56 -0500

Guy,

Thanks for the clarification. As you note, the advertisements sent to 
the subscribers are not an issue. any stub subscriber in this example 
has but one path to everywhere, through X, so BGP security is 
irrelevant to their routing decision.

In the other direction, as Sandy noted, one could create a capability 
to nominate any AS, vs. a specified set of ASes, to originate one's 
prefix, if needed. But, if X fails to add it's AS # to the path when 
it originates an advertisement, then it seems to fail the basic, BGP 
test for verifying that X is the peer, a more serious problem.I

If each subscriber authorized each tier 1 AS who they are paying to 
advertise its prefixes, then the model would work, and X would only 
have to act as an intermediary to collect the fees :-).  After all, 
you said each subscriber chooses which tier 1's X will advertise the 
prefixes of the subscriber, so the subscribers know who to authorize.

One also might try to create a secure, transitive, authorization to 
originate capability if one needs to mimic this operational model 
very closely.

Steve