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

From: Sandy Murphy <[email-masked]>
Date: Fri, 21 Jan 2005 12:34:17 -0500 (EST)

>> >-- Overlapping address spaces exist.
>>
>> I don't know what you mean by this.
>...
>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.

So what you are saying (and what I was trying to get Russ to say)
is that what is overlapping is the authority over the address
space - two ISP's have been allocated an address space.

>The name I use for the above case is an "implicit aggregate".
>...
>I call this case an "explicit" or
>"proxy" aggregate.

I've heard different opinions on how common the proxy aggregation
case is.  One example of the security requirement process would be to
decide if this was a semantics we wanted to retain and secure
and if so how.  (Implicit aggregation - you just have to show
your allocation from someone else, where that might be IANA. Proxy
aggregation - you have to show .... that you received two updates
that add up to the aggregated prefix???  At any rate, it's nay
so easy.)

--Sandy

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Jan 2005 12:12:42 -0500

> that add up to the aggregated prefix???  At any rate, it's nay

I believe the suggestion I made on bgpsecreq is that one can't readily
describe a proxy aggregate as being a secure route.  Therefore, 
this is a good target for transitive local trust (perhaps the wrong
terminology).  

By way of example, if I advertise a proxy aggregate, I can verify from
the originating party that they've claimed to originated the route,
and that they don't claim to "own" the route.  I may then choose
based on my trust metric via the people who have propagated the route
whether or not I'll accept that route.  I know that I can't trace
the route to IANA delegation.

Tracing the originating party is problematic.  The process of generating
an aggregate will change the AS_PATH.  The AS portion of the AGGREGATOR
could be used for the authorization operation, but AGGREGATOR may
be overwritten upon the next aggregation operation.

Dealing with this case in the security infrastructure cleanly may
require BGP protocol changes, although mild ones.

-- 
Jeff Haas 
NextHop Technologies