Subject: Re: [RPSEC] proposed message to the IESG

From: Sandy Murphy <[email-masked]>
Date: Fri, 21 Jan 2005 10:41:11 -0500 (EST)

>-- Overlapping address spaces exist.

I don't know what you mean by this.  I get the mental image of the
same address being used by two hosts, but surely that's not what's
meant, so I'm guessing you mean that authorization for the same
address space can overlap - that is, two organizations can be
allocated the same address space.

BTW, if that's what you meant, then I'd say this is not a security
problem, as long as there's a hierarchy involved in the overlap.
It would be a problem if A was allocated some addressees and then
allocated a subset to B and the same subset to C.  I presume (you
can correct me) that this is not viewed kindly, even in the
twisty world of ISP business arrangements :-).

Security authorizations aren't like resource allocations.  If you
delegate to someone you don't give up the right yourself.  It
doesn't work like memory allocations, where if you give part of
your memory allocation to a subprocess you give up the right to
use it yourself.  It works like read permissions - if you give
someone the right to read a file you can read, you don't lose
the ability to read it yourself.

So sub-address block allocations (if that's what you meant)
don't cause a problem in checking authorization to advertise
the block you're allocated.

--Sandy

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

---

From: Blaine Christian <[email-masked]>
Date: Fri, 21 Jan 2005 11:13:54 -0500

I can give you one!  Anycast for DNS...  Anycast is very cool...  But
everyone uses the same prefix.

---

From: Russ White <[email-masked]>
Date: Fri, 21 Jan 2005 11:36:23 -0500 (Eastern Standard Time)

> I don't know what you mean by this.  I get the mental image of the same 
> address being used by two hosts, but surely that's not what's meant, so 
> I'm guessing you mean that authorization for the same address space can 
> overlap - that is, two organizations can be allocated the same address 
> space.

In a sense, yes, and in a sense, no.

-- A is allocated 10.1.0.0/16.
-- A suballocates 10.1.1.0/24 to B.

IMHO, we care about routes, not updates, and routes contain prefixes. One 
of the questions we can ask about those prefixes is: Is the originator 
authorized to advertise the address space in the route? In this case, A can 
advertise 10.1.0.0/16, and the answer is yes, even though it actually 
contains 10.1.1.0/24, for which the answer is technically no.

So, in a sense, this address space, 10.1.1.0/24, is legally "owned" by two 
entities within the system. Other than redoing the entire allocation 
scheme, or disallowing aggregation (forcing A not to advertise 10.1.0.0/16 
when it suballocates space out of it), I don't see how you get around this 
problem.

It's certainly easier to just say: "We'll just worry about the path the 
update takes, and not worry about this problem. We'll assume that if you're 
authorized to readvertise the update, you're authorized to transit for this 
address space, and we'll also assume you're authorized to allow me to 
readvertise this address space."

IMHO, this sort of transitive trust can't exist within a routing system. We 
need to focus on the questions we can ask, and base the requirements on 
them, rather than the process used to handle updates according to the BGP 
specification.

:-)

Russ

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

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Jan 2005 11:57:31 -0500

Sandy,

> allocated the same address space.

In this case, it's CIDR as usual.  I can own a larger block, say a /8,
delegate a smaller block from that, say a /24, and still advertise
my /8.

When a BGP speaker announces a shorter prefix and not a longer prefix
that it has, this is a form of aggregation.  In the case where
the AS_PATH is different, this is a form of ATOMIC_AGGREGATE.  However,
the BGP specification never covered the case for marking a route
with ATOMIC_AGGREGATE in the adj-rib-out - it only did this on selecting
the route into loc-rib.

The name I use for the above case is an "implicit aggregate".
This is because you are not creating a new shorter prefix where none
previously existed.  This is to distinguish it from the other
case where a new route is created -  I call this case an "explicit" or
"proxy" aggregate.  In this case, a new, shorter prefix route is
created.  This will usually involve either ATOMIC_AGGREGATE being set
on the path attributes because the AS_PATH has been truncated or
an AS_SET has been generated.

The security implications of delegated address space where an implicit
aggregate may be present are one of our items of concern.  The fact
that some provider may be using this delegated space implies two
things operationally from a forwarding perspective:

Consider the owner of the /8 to be ISP-A and the delegated /24 to
be ISP-B.

1. If ISP-A and ISP-B are connected in some fashion, either
   directly or indirectly, ISP-A may be willing to forward traffic
   to ISP-B and will need ISP-B's /24 in order to do this.
2. If ISP-A and ISP-B are not connected in some fashion and ISP-A is
   unwilling to forward traffic for the covered /24, there may be
   occasions where ISP-B's traffic is blackholed.

The implication is no matter how secure the /8 and the /24 routes are,
if ISP-A and ISP-B must have some relationship for traffic
for the covered /24 as ISP-A may, simply due to CIDR, receive that
traffic.  Ergo, if you're concerned about this situation, the only
way to be truly sure about the forwarding is to get your own address
space.  Even then, if someone proxy aggregates and your route is
filtered, they may still intercept your traffic simply using routing
protocols (excluding a man-in-the-middle attack on the forwarding plane).

-- 
Jeff Haas 
NextHop Technologies

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jan 2005 17:06:30 -0500

At 11:36 AM -0500 1/21/05, Russ White wrote:
>IMHO, we care about routes, not updates, and routes contain 
>prefixes. One of the questions we can ask about those prefixes is: 
>Is the originator authorized to advertise the address space in the 
>route? In this case, A can advertise 10.1.0.0/16, and the answer is 
>yes, even though it actually contains 10.1.1.0/24, for which the 
>answer is technically no.
>
>So, in a sense, this address space, 10.1.1.0/24, is legally "owned" 
>by two entities within the system. Other than redoing the entire 
>allocation scheme, or disallowing aggregation (forcing A not to 
>advertise 10.1.0.0/16 when it suballocates space out of it), I don't 
>see how you get around this problem.
>
>It's certainly easier to just say: "We'll just worry about the path 
>the update takes, and not worry about this problem. We'll assume 
>that if you're authorized to readvertise the update, you're 
>authorized to transit for this address space, and we'll also assume 
>you're authorized to allow me to readvertise this address space."
>
>IMHO, this sort of transitive trust can't exist within a routing 
>system. We need to focus on the questions we can ask, and base the 
>requirements on them, rather than the process used to handle updates 
>according to the BGP specification.
>
>:-)
>
>Russ
>

Russ,

You persist in using terms that you ascribe to the models proposed by 
others (e.g., Sany or me), but we either don't use those terms, or 
don't use the the way you define them.  Sandy pointed out this 
problem earlier when you kept using the term "prove" and I'll note it 
again here for the phrase "transitive trust." Don't do this; it 
confuses matters and in no way helps support your arguments.

Steve