Subject: [RPSEC] A Question on Authorization....

From: Russ White <[email-masked]>
Date: Sat, 5 Feb 2005 17:46:07 -0500 (Eastern Standard Time)

Y'all:

I'm still somewhat confused by the different meanings of "authorize" being 
used on list, so I'd like to ask a couple of simple questions, to perhaps 
allow everyone to come to a little better understanding. Suppose we have 
this:

A---B---C
|   |
D---+

Now, suppose A has obtained 10.1.1.0/24 from D. A advertises this prefix to 
B, who then advertises it to C. I would like to know:

-- Does A's advertisement to B, in the absence of any other communities, 
etc, authorize B to advertise 10.1.1.0/24 to C?

-- Does A's advertisement to B, in the absence of any other communities, 
etc, authorize B to transit 10.1.1.0/24 from C to A?

-- Suppose A were to use some technique, NO_EXPORT, an AS Path TTL, 
NO_PEER, redistribution communities, etc, etc, to prevent B from 
advertising 10.1.1.0/24 to C. Does this imply that A is _not_ authorizing B 
to transit for 10.1.1.0/24 from C to A? That if B does happen to transit 
traffic destined to 10.1.1.0/24 from C to A, it is "outside it's 
authorization limits?"

If the answer to the last question is yes, is this the specific sort of 
thing people would like to be able to "authorize" in a system used to 
secure BGP--that B, in this case, is or is not authorized to transit for 
10.1.1.0/24 from C to A?

If the answer to the last question is no, what other meaning is there 
attached to the concept of "authorization?" In other words, if A authorizes 
B to send routing information to C, what does that mean, exactly, if it 
doesn't mean B is now authorized to transit for 10.1.1.0/24 between A and 
C? That C is authorized to send it to one of their peers, and nothing more? 
What can it mean to authorize a peer to send routing information to their 
peers, if not that the peer you're sending the routing information to is 
now authorized to transit for the prefixes you're sending?

:-)

Russ

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

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

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 7 Feb 2005 12:05:00 +0100

I think that what you are asking about lies outside the scope of this work.

The model for (most of) the past decade is that RIRs allocate to LIRs (Local
Internet Registry) who can suballocate to Resellers.  The LIR remains
responsible for the allocation.  And this suballocation is of Provider
Aggregatable space so the LIR should advertise the allocation (or part thereof),
the Reseller should not.

So the authorization is implicit in the allocation and only goes from RIR to
LIR, no further.

(If an organisation wants to multihome, then it needs a Provider Independent
allocation and this is handled differently; it is non-aggregatable and the RIR
retains more control).

This is the scheme I believe we should focus on.  Of course the BGP4
specification allows much more complex schemes but that does not mean we have to
secure them.  (And legacy allocations predate this scheme and probably contain
arrangements that are inimical to any security system:-(

Terminology matters; 'owns' is wrong in this scheme, 'obtains' - as you use -
depends on the semantics you have in mind:-)  'Allocates' is correct.

My information is based on RIPE but I understand that AFNIC, APNIC, ARIN and
LACNIC all follow the same principles.

Tom Petch

---

From: Stefan Mink <[email-masked]>
Date: Mon, 07 Feb 2005 22:12:58 +0100

Hi Russ,

Russ White wrote:

> I'm still somewhat confused by the different meanings of "authorize" 
> being used on list, so I'd like to ask a couple of simple questions, 
> to perhaps allow everyone to come to a little better understanding. 
> Suppose we have this:
>
> A---B---C
> |   |
> D---+
>
> Now, suppose A has obtained 10.1.1.0/24 from D. A advertises this 
> prefix to B, who then advertises it to C. I would like to know:
>
> -- Does A's advertisement to B, in the absence of any other 
> communities, etc, authorize B to advertise 10.1.1.0/24 to C?

This is only true in general, iff the readvertisement scope of B to C is 
not restricted
(i.e. "transit-provider - customer" relationship)

Otherwise it depends on the other relationships, e.g. if A-B is a 
transit provider - customer
relationship ("down") and B-C is a customer - transit provider 
relationship ("up"), B is not authorized to
readvertise the route to C. This is described by some people as the 
"valleyfreeness of the internet".

> -- Does A's advertisement to B, in the absence of any other 
> communities, etc, authorize B to transit 10.1.1.0/24 from C to A?

it's inevitably linked to the last question. If B is not authorized to 
readvertise the route
to C, it's not authorized to transit traffic from C to A *on this path*. 
There may be
others...

> advertising 10.1.1.0/24 to C. Does this imply that A is _not_ 
> authorizing B to transit for 10.1.1.0/24 from C to A? That if B does 
> happen to transit traffic destined to 10.1.1.0/24 from C to A, it is 
> "outside it's authorization limits?"

since BGP is currently not based on authorization (nobody has to 
demonstrate he's authorized
to (re)advertise a prefix), the means described above are used to 
communicate "negative
authorizations", i.e. "prohibitions". So A is trying to prevent B from 
readvertising the route
and by this attract traffic for the route via the path "B-A". So the 
general response is: yes.

> If the answer to the last question is yes, is this the specific sort 
> of thing people would like to be able to "authorize" in a system used 
> to secure BGP--that B, in this case, is or is not authorized to 
> transit for 10.1.1.0/24 from C to A?

this is one of the cases, yes. The problem here is, that it's not a good 
idea to do it
like this. If C is a single homed customer of B and A prevents B from 
readvertising
the prefix *at all*, this means that C will have no route to 10.1.1.0/24 
at all.
Thats why in general it's probably more based on classes of readvertisement
scopes ("customer-transit", "peering", "transit-customer"). So it's more 
restricting
the readvertisement scope of B for this route to a minimum, i.e. to 
customers
only...

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

---

From: Russ White <[email-masked]>
Date: Mon, 7 Feb 2005 16:49:47 -0500 (Eastern Standard Time)

> demonstrate he's authorized to (re)advertise a prefix), the means 
> described above are used to communicate "negative authorizations", i.e. 
> "prohibitions". So A is trying to prevent B from readvertising the route 

So, what you're really saying is you want to be able to say: "C is not 
authorized to transit 10.1.1.0/24." Saying: "A should be able to authorize 
B to transmit routing information to C" is a completely different problem, 
in reality.

To see why this is:

-- Suppose A is advertising 10.1.1.0/24 to B in such a way that B cannot
    readvertise it to C. According to your email above, this should mean
    that A is _not_ authorizing B to transit traffic from C.
-- Suppose D is advertising 10.1.0.0/16 to B, and authorizes B to advertise
    10.1.0.0/16 to D.

D forwards traffic destined to hosts within 10.1.1.0/24 along the path to 
10.1.0.0/16. C routes this traffic along the longest match, causing the 
traffic to flow to A, and thus B becomes a transit for traffic destined to 
10.1.1.0/14, correct?

Is B still not authorized to transit traffic for A, even though it is, in 
reality, doing so? How has A blocking its routing information from 
transiting B actually provided what you are saying you want--to block B 
from transiting traffic for 10.1.1.0/24 towards A? It doesn't appear that 
blocking the routing information has solved anything, in this case.

So, it seems to me that it's better to actually state that BGP has no 
concept of authorization to transit, based on the advertisements in BGP 
itself. This might be a useful security feature to add (if it's even 
technically possible to add it), but it's not something BGP has at the 
moment, implicitely or explicitely.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Mon, 7 Feb 2005 17:38:30 -0500 (Eastern Standard Time)

>>> Now, suppose A has obtained 10.1.1.0/24 from D. A advertises this prefix 
>>> to B, who then advertises it to C. I would like to know:
>
>>> advertising 10.1.1.0/24 to C. Does this imply that A is _not_ authorizing 
>>> B to transit for 10.1.1.0/24 from C to A? That if B does happen to transit 

BTW, I'd really like some other folks to chime in on this answer. I want to 
understand what everyone thinks the meaning of "authorization" means in 
terms of BGP's readvertisement of routing information (not origination, 
just readvertisement).

Thanks!

:-)

Russ

---

From: Stefan Mink <[email-masked]>
Date: Tue, 08 Feb 2005 00:23:01 +0100

Russ White wrote:

> D forwards traffic destined to hosts within 10.1.1.0/24 along the path 
> to 10.1.0.0/16. C routes this traffic along the longest match, causing 
> the traffic to flow to A, and thus B becomes a transit for traffic 
> destined to 10.1.1.0/14, correct?

yes

> Is B still not authorized to transit traffic for A, even though it is, 
> in reality, doing so? How has A blocking its routing information from 
> transiting B actually provided what you are saying you want--to block 
> B from transiting traffic for 10.1.1.0/24 towards A? It doesn't appear 
> that blocking the routing information has solved anything, in this case.

You're right that in this case this wouldn't work thanks again to the
concept of aggregation. On the other hand this does not mean to me
that the concept is useless altogether, but that currently there may be some
restrictions for aggregates and more specifices. This is due to
the concept of routing based on destination address independently
of the source address. Juniper routers (I'm not sure with GSRs)
can handle several separate routing tables and here it would
indeed be possible by using "filter based forwarding" to use different 
routing
tables if there are different authorization schemes. So its entirely
possible that current mechanisms have to be extended to implement
complicated authorization schemes.

I have actually discussed this two years ago with a provider to which we 
have
a mixed peering and transit relationship. Here by means of different 
routing
tables it would have been possible to forward peering traffic (his 
customers -
my customers) using one table (and certain forwarding paths) and to forward
transit traffic (rest of the internet - my customers) using another 
table and
different forwarding paths.

This is technically possible but we dropped it since it would have been 
a special
solution and special solutions are hard to maintain...

> concept of authorization to transit, based on the advertisements in 
> BGP itself. This might be a useful security feature to add (if it's 
> even technically possible to add it), but it's not something BGP has 
> at the moment, implicitely or explicitely.

ACK

   tschuess
             Stefan Mink

---

From: [email-masked]
Date: Tue, 8 Feb 2005 01:03:29 +0000

On Mon, Feb 07, 2005 at 05:38:30PM -0500, Russ White wrote:
> >>>being used on list, so I'd like to ask a couple of simple questions, to 
> >>>perhaps allow everyone to come to a little better understanding. Suppose 
> >>>we have this:
> >>>
> >>>A---B---C
> >>>|   |
> >>>D---+
> >>>

	if a BGP process in a router has knowledge of a prefix, its 
	"authorized" to propogate its knowledge (to the extent controled
	by local re-distribution policies).  how it gains its knowledge (via 
	iBGP, eBGP, some random IGP, or static entries that are manually
	configured and distributed into BGP... is generally -NOT- part of
	the BGP protocol spec.  
	and even tho there are "knobs" to try and influence redistribution
	beyond the immediate peer, the locus of control is in that bi-lateral
	agreement that is the basis of BGP.  Its not quite Alice/Bob, but
	its close... :)

--bill

---

From: Guy Tal <[email-masked]>
Date: Tue, 8 Feb 2005 01:43:19 -0500 (EST)

> terms of BGP's readvertisement of routing information (not origination,

I've seen many networks out there allow their customers to prepend AS or
even deny certain prefixes to certain other networks by use of BGP
communities. If a customer of one of those networks decides it doesn't
want traffic from a certain network to traverse a certain upstream, the
upstream must comply with that decision.

Peers advertise routes to other peers with the intention of connecting
their customers with their peers' customers. I would say in this
relationship, the network in question should not advertise those routes to
its other peers. Funny business aside, it's not in a network's best
interests to transit one peer's traffic for free. This is usually
reinforced in a contract as well, in which case the "should not" changes
to "must not" or the network transitting the traffic will face depeering.

Guy Tal
Global Crossing
Traffic Engineering

---

From: Birger Tödtmann <[email-masked]>
Date: Tue, 08 Feb 2005 11:03:41 +0100

Am Montag, den 07.02.2005, 17:38 -0500 schrieb Russ White:
[...]
> terms of BGP's readvertisement of routing information (not origination, 

I think "authorization" always comes with an instance who grants it.
And it also implies an enforcement decision, hopefully a deterministic
one.  Without both, authorization is an empty phrase.  Unfortunately
these accompanying characteristics are not easy to nail down here:

- In your example A has obtained 10.1.1.0/24 from D.  D in this case 
  implicitly authorizeses A to re-advertise the prefix.  The design of
  the inter-domain routing system also implicitly authorizes A to 
  forward any traffic for 10.1.1.0/24 to D, be it from someone else or 
  A's own network.

- A then re-advertises the prefix to B.  Supposed it uses some mechanism
  like NO_EXPORT, A denies authorization to B to re-advertise the 
  prefix.  In comes the enforcement decision: B now has a choice.
  Obviously, D not only authorized A to re-advertise its prefix, it 
  also may have *wanted* it to re-advertise the prefix through the  
  whole net.  Instead, A denies this explicitly to B.  So we possibly
  have conflicting policies here.  B can now choose between three
  alternatives:

  - ignore any outside policies, follow your own (grant/deny
    authorization to yourself)
  - follow B's policy (authorization denied by B)
  - follow D's policy (authorization granted by D)

BGP right now has no mechanism to assess rightfully who granted or
denied authorization to re-advertise a prefix.  It has no mechanism to
show conflicting authorizations (that result from conflicting policies).
And it also has no deterministic decision process that makes clear which
authorization, if known, has to be followed at a certain point.

IMHO, operators, not the BGP spec, set down some rules of their own to
avoid complete chaos:

 - Check some external database (authorization granted / denied from
   trusted third party)
 - Follow authorization grants/denials from adjacent BGP peers
   (to be on good terms with the direct neighbor is always more
    important than to please someone who lives three blocks away)

Regards,
-- 
Birger Tödtmann
Technik der Rechnernetze, Institut für Experimentelle Mathematik
Universität Duisburg-Essen, Campus Essen email:[email-masked]
skype:birger.toedtmann pgp:0x6FB166C9

---

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Feb 2005 09:24:38 -0500

>communities, etc, authorize B to advertise 10.1.1.0/24 to C?

yes.

>communities, etc, authorize B to transit 10.1.1.0/24 from C to A?

Authorization, as I have used the term on this list, refers to 
permission for  an AS to forward an advertisement; it does not apply 
directly to an AS's willingness to forward traffic.  However, the two 
are linked, i.e., it is inappropriate to advertise a prefix for 
traffic that you do not intend to forward to the destination. So, in 
this case, A should not advertise the /24 to B with an implicit 
authorization to further advertise that prefix, unless A has an 
agreement with B in which B agrees to forward transit traffic.

>"outside it's authorization limits?"

If A advertises the /24 to B with NO_EXPORT, then it is telling B to 
not forward that advertisement to anyone else. As noted above, 
authorization does not apply directly to forwarding, but yes, if B 
forwards this /24 traffic from C, then it would be acting in a 
fashion inconsistent with the advertisement from A. However, note 
that authorization for advertisements has not been suggested as a 
substitute for agreements between peers that define traffic 
forwarding constraints.

>of thing people would like to be able to "authorize" in a system 
>used to secure BGP--that B, in this case, is or is not authorized to 

One can raise the question of whether it is desirable to enhance BGP 
to express the info now contained in peer agreements that are outside 
the scope of BGP. However, since some ISPs have expressed a desire to 
not propagate this sort of info, putting it into BGP advertisements 
may not be a good idea.

>If the answer to the last question is no, what other meaning is 
>there attached to the concept of "authorization?" In other words, if 
>A authorizes B to send routing information to C, what does that 
>mean, exactly, if it doesn't mean B is now authorized to transit for 
>10.1.1.0/24 between A and C? That C is authorized to send it to one 
>of their peers, and nothing more? What can it mean to authorize a 
>peer to send routing information to their peers, if not that the 
>peer you're sending the routing information to is now authorized to 
>transit for the prefixes you're sending?

Authorization for route advertisements provides several security 
benefits distinct from the issue you raise here.

	- route authorization protects an originating AS (A) from 
having other ASes accept routes for prefixes originated by A, as a 
result of bogus (unauthorized) advertisements by other ASes. this 
helps protect the traffic forwarded to A from ASes around the 
Internet, in terms of misrouting.

	- route authorization allows ASes to detect and reject bogus 
(unauthorized) routes. this is the complement of the above bullet, in 
that it tries to prevent unauthorized forwarding from the perspective 
of a senders of traffic, vs. a receiver.

The question you asked is whether a peer is "authorized to transit 
[sic] for the prefixes you're sending?" Whether a peer will forward 
traffic for a specified prefix to you from other ASes is not a matter 
of "authorization" as we have described the term.  It is a separate 
issue of a business agreement between the ASes in question. However, 
you are right to note that if AS A authorizes a peer (B) to advertise 
a prefix to other ASes, then A should do so only if it has an 
agreement with B to cause the traffic for the prefix to transit B.

If A fails to have such an agreement, B should not propagate the 
advertisement, since doing so will likely cause traffic to come to B 
that B does not want to forward. Similary, A should not send such an 
advertisement to B unless there is a traffic forwarding agreement in 
place, as B will likely drop the traffic in the absence of such an 
agreement. So, yes, if A makes a mistake and advertises a prefix to B 
with implicit authorization to forward the advertisement, and if B 
propagates the advertisement, despite the lack of an agreement to 
forward the transit traffic for A, then traffic to A may fall on the 
floor. (Or, if B is so sloppy, it may be forwarded anyway :-))

However, these failure modes are a form of self-inflicted damage, 
done by A to A, with some "help" from B. The adverse effects are a 
lot more limited in scope than what results from propagation and 
acceptance of generic, bogus route advertisements.

Steve