Subject: [Sidr] Re: S-BGP and IP prefix aggregation

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 2 Dec 2005 00:22:44 -0800 (PST)

[I'm cross-posting this to SIDR BOF (future SIDR WG) list as that seems
  to be the most appropriate forum to discuss this issue]

On Fri, 2 Dec 2005, <[email-masked]> wrote:

> I have a question about S-BGP. When IP prefix is aggregated, and a 
> S-BGP speaker receives a route announcement with the aggregated ip 
> prefix,
>
> how does it verify the authority of the AS to announce the IP prefix. 
> The aggregated IP prefix should have not address attestation.

With rare exceptions almost all aggregation happens by ISP that has been
allocated larger block and which it sub-allocated to its customers (or 
decided to break of and announce subparts from multiple datacenters), so 
in this case ISP (ASN) would obviously be able to provide a permission 
[sign cert] to announce that larger block.

There are however some rare exceptions, for example I know of ip block
in legacy class-c space that UUNET is announcing as /16 aggregate but
where it actually consists of a number of smaller ip blocks assigned 
(direct assignment from RIR) to several different organizations.

I always assumed myself that those running SIDR aware routers in such cases
would not be doing aggregation - i.e. no aggregation if each ip block in 
the aggregate has permission for announcement from different entity.

An alternative for sbgp design could be that aggregating ASN would create 
special self-signing cert for such aggregate block and that cert would 
have special attribute(s) indicating list of all sub-blocks and reference
to all certs that "make" this aggregate block. Then verifying router
in such a case would go through and verify each one of those sub-block
certs (and those sub-block certs would have to be such that they give 
permission for announcing the block from that sub-block owner to 
aggregating ASN).

-- 
William Leibzon
Elan Networks
[email-masked]

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

---

From: Tony Li <[email-masked]>
Date: Fri, 2 Dec 2005 00:41:37 -0800

>
> An alternative for sbgp design could be that aggregating ASN would  
> create special self-signing cert for such aggregate block and that  
> cert would have special attribute(s) indicating list of all sub- 
> blocks and reference
> certs (and those sub-block certs would have to be such that they  
> give permission for announcing the block from that sub-block owner  
> to aggregating ASN).
>

Advertising an aggregate that is not specifically assigned to you is  
known as "proxy aggregation".
William has given a good description of what's required above, but it  
needs a further enhancement
in that proxy aggregation will frequently need to happen in several  
locations for the aggregate to
have any true impact on routing.  In graph theoretic terms, proxy  
aggregation must form a
"cut set" topologically around the longer prefixes to contain them  
and prevent them from being
distributed throughout the network.

Thus, any security mechanism needs to provide some means for  
indicating that
an entire set of ASes may legitimately be advertising a proxy  
aggregate prefix.  How one
determines the appropriate set of ASes that are authorized is another  
interesting administrative
issue that needs to be resolved.

Tony

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Dec 2005 10:38:02 -0500

At 12:22 AM -0800 12/2/05, william(at)elan.net wrote:
>>how does it verify the authority of the AS to announce the IP 
>>prefix. The aggregated IP prefix should have not address 
>>attestation.
>
>allocated larger block and which it sub-allocated to its customers 
>(or decided to break of and announce subparts from multiple 
>datacenters), so in this case ISP (ASN) would obviously be able to 
>provide a permission [sign cert] to announce that larger block.
>
>would not be doing aggregation - i.e. no aggregation if each ip 
>block in the aggregate has permission for announcement from 
>different entity.
>
>cert would have special attribute(s) indicating list of all 
>sub-blocks and reference

I don't know if we should be going into quite this much detail at this stage.

However, I would avoid suggestions to use of self-signed certs in the 
way suggested above. Remember that a self-signed cert has relatively 
little security value in a PKI. We use a self-signed cert primarily 
to represent a public key for a trust anchor, because it allows reuse 
of the cert format and that's convenient. Also, certs (vs. other 
forms of signed objects) are probably not the best way to represent 
the authorization of an AS to advertise address space.

Steve

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 2 Dec 2005 08:43:57 -0800 (PST)

On Fri, 2 Dec 2005, Stephen Kent wrote:

>> special self-signing cert for such aggregate block and that cert would have 
>> special attribute(s) indicating list of all sub-blocks and reference

Well, the BoF charter discussions would be higher priority but seeing as 
it seemed to have already been sent and discussions closed, why not 
discuss some possible protocol features.

> However, I would avoid suggestions to use of self-signed certs in the way 
> suggested above. Remember that a self-signed cert has relatively little 
> security value in a PKI.

I agree. But in this case that this cert has little value only works in 
our favor as security software would more clearly see that it needs to
disregard it "security value" and focus on the security provided by the 
referenced certs for portions of aggregated block as being the key to
deciding if the ip block announcement is ok or not.

BTW - self-signed as I used it above also includes when ASN uses its 
own organization's key (which could be signed by RIR) to create this 
cert (i.e. its signed by ASN about ASN), it does not have to be real 
self-signed cert in the x509 way.

> We use a self-signed cert primarily to represent a public key for a 
> trust anchor, because it allows reuse of the cert format and that's 
> convenient. Also, certs (vs. other forms of signed objects) are 
> probably not the best way to represent the authorization of an AS to 
> advertise address space.

I personally often use the word "cert" to mean any type of PKI signed
structured object (no matter if its x509 cert or not). The exactly format 
is definitely something to be discussed and decided by the WG and is a 
reason why I said that decisions on how to publish and propagate
authorization data and the format should be part of the WG work area.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Dec 2005 14:30:19 -0500

At 8:43 AM -0800 12/2/05, william(at)elan.net wrote:
>Well, the BoF charter discussions would be higher priority but 
>seeing as it seemed to have already been sent and discussions 
>closed, why not discuss some possible protocol features.

OK.

>>However, I would avoid suggestions to use of self-signed certs in 
>>the way suggested above. Remember that a self-signed cert has 
>>relatively little security value in a PKI.
>
>I agree. But in this case that this cert has little value only works 
>in our favor as security software would more clearly see that it 
>needs to
>disregard it "security value" and focus on the security provided by 
>the referenced certs for portions of aggregated block as being the 
>key to

there is a lot of open source software to process certs, and it would 
not react well to this sort of use of a self-signed cert.

>self-signed cert in the x509 way.

I'd ask that we stick with the standards-based definitions for PKI 
objects, whenever possible, to minimize confusion.

>>probably not the best way to represent the authorization of an AS 
>>to advertise address space.
>
>structured object (no matter if its x509 cert or not). The exactly 
>format is definitely something to be discussed and decided by the WG 
>and is a reason why I said that decisions on how to publish and 
>propagate

One can use the term cert more broadly, but it adds confusion to an 
already complex topic.  We're certainly free to define digitally 
signed objects to meet application-specific requirements, just as 
S/MIME makes use of CMS as a basis for secure e-mail formats.  But it 
makes the discussion more precise if we use the term cert (public key 
cert is more precise but the qualifier is usually omitted) to refer 
to signed structures that bind a public key to a set of attributes.

The security ADs (who will eventually review our documents) frown on 
the creation of new mechanisms or data structures when there are 
existing IETF standards that meet the needs of an application :-).

Note that the IETF has explored various cert formats in the past. For 
example, we had the SPKI WG for a while, but it closed and yielded no 
standards track RFCs. Most IETF security protocols (e.g., IPsec, 
S/MIME, TLS) make use of X.509 certs. The PKIX WG has developed both 
profiles for X.509 standards as well as IETF-specific protocols for 
these certs, e.g., OCSP and SCVP. When Harald asked if Geoff 
envisioned use of the RFC 3779 cert extension to represent address 
space and AS number data, the response was "yes."  So, given this 
background I think it's reasonable to assume use of X.509 certs 
unless we find them to be lacking in some serious fashion.

Stve

---

From: Tony Li <[email-masked]>
Date: Fri, 2 Dec 2005 11:39:37 -0800

> there is a lot of open source software to process certs, and it  
> would not react well to this sort of use of a self-signed cert.

Gents,

Could I help elide this discussion?

If we do proxy aggregation correctly and coordinate it amongst a  
number of different ISPs, then the
cert should not be self-signed.  In fact, it needs to derive  
authorization from the coordinating body.

One might imagine an "IETF Proxy Aggregation" entity which would sign  
these certs.

Regards,
Tony

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Dec 2005 15:26:45 -0500

At 11:39 AM -0800 12/2/05, Tony Li wrote:
>One might imagine an "IETF Proxy Aggregation" entity which would 
>sign these certs.
>
>Regards,
>Tony

We started with the notion that address space holders authorize ISPs 
to originate routes. When aggregation of routes takes place at a 
point that is not known by the address space holders, we need to 
agree on who makes sense to authorize the aggregation. I would not 
necessarily expect there to be a single entity for such 
authorization, since the address space holders, route originators, 
and aggregation points are potentially independent and distinct.

Steve

---

From: Tony Li <[email-masked]>
Date: Fri, 2 Dec 2005 16:16:58 -0800

> We started with the notion that address space holders authorize  
> ISPs to originate routes. When aggregation of routes takes place at  
> a point that is not known by the address space holders, we need to  

Steve,

For proxy aggregation to work in any useful manner, there is an  
entire perimeter, not a single point
where the aggregation takes place.  Thus, there needs to be  
coordination of all entities around that
perimeter.  For anti-trust issues alone, I'd suggest that this would  
need to be a single, collaborative
entity.

Tony

---

From: Geoff Huston <[email-masked]>
Date: Mon, 05 Dec 2005 14:28:58 +1100

>discuss some possible protocol features.

The ADs asked for a draft charter by the end of November, so, yes, the 
draft charter has now been shipped to the Routing Area ADs. I have heard 
nothing back at this stage.

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Mon, 05 Dec 2005 14:39:19 +1100

>One might imagine an "IETF Proxy Aggregation" entity which would sign

So what are we looking for in an proxy aggregated announcement?

  - that the aggregate is made of up only of valid addresses? (i.e. that an 
aggregate cannot span unallocated address space) yes? no?

- that the aggregate was formed only by component prefixes where valid 
routing authorities existed? Or a heterogenous collection of prefixes, some 
with authority credentials and some not?

- Should the aggregate prefix announcement have associated credentials? 
Tony above appears to be suggestion that this is a coordinated action with 
a set of entities who then jointly attest to the validity of the authority 
action, if I am reading his note correctly. Is proxy aggregation truly a 
coordinated action? Or do various forms of unilateration proxy aggregation 
exist?

- in an environment where the security module is intended to present the 
origination credentials to a receiver to allow the receiver to check the 
validity of an announcement, is it possible to validate the credentials 
(and the correctness) of a proxy aggregator?

    Geoff

---

From: Tony Li <[email-masked]>
Date: Sun, 4 Dec 2005 23:59:48 -0800

Geoff,

>  - that the aggregate is made of up only of valid addresses? (i.e.  
> that an aggregate cannot span unallocated address space) yes? no?

I'd argue that as long as it has properly credentials, it doesn't  
matter.  It is up to the coordinating
body to determine what to proxy aggregate and to determine the ASes  
that will be authorized to
advertise the aggregate.

> - that the aggregate was formed only by component prefixes where  
> valid routing authorities existed? Or a heterogenous collection of  
> prefixes, some with authority credentials and some not?

Since the longer prefixes are hopefully not being globally  
circulated, it would be difficult to verify these
properties externally.  Certainly, accepting such an aggregate is  
placing operational trust in the
advertiser, above and beyond what we would expect from normal prefix  
distribution.

> - Should the aggregate prefix announcement have associated  
> credentials? Tony above appears to be suggestion that this is a  
> coordinated action with a set of entities who then jointly attest  
> to the validity of the authority action, if I am reading his note  
> correctly. Is proxy aggregation truly a coordinated action? Or do  
> various forms of unilateration proxy aggregation exist?

We've tried proxy aggregation as a unilateral function before and  
even as an semi-coordinated multilateral function.  It failed  
miserably due to the traffic engineering side effects.  Hopefully, if we
coordinate our efforts and anticipate and compensate for those  
results prior to putting an
aggregate in place, we will be able to avoid this.

> - in an environment where the security module is intended to  
> present the origination credentials to a receiver to allow the  
> receiver to check the validity of an announcement, is it possible  
> to validate the credentials (and the correctness) of a proxy  
> aggregator?

It should be, as I outlined above, by presenting a delegation from a  
trusted central coordinating body.

Tony

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Dec 2005 11:43:29 -0500

>need to be a single, collaborative

Tony,

We seem to agree that the goal is to ensure that each AS advertising 
itself as the origin for a route is authorized to do so. While it may 
be necessary to introduce an additional entity to attest to this 
authorization in  the case of proxy aggregation, I'd hate to have us 
assume this as a starting point. Also, from a security perspective, 
it is preferable to rely upon as few parties as possible, to minimize 
opportunities for failure. So, I suggest we work our way through the 
easy cases and then deal with proxy aggregation, to determine if it 
is necessary to introduce an additional entity to issue a credential 
for proxy aggregation.

Steve

---

From: Tony Li <[email-masked]>
Date: Mon, 5 Dec 2005 09:27:06 -0800

> So, I suggest we work our way through the easy cases and then deal  
> with proxy aggregation, to determine if it is necessary to  
> introduce an additional entity to issue a credential for proxy  
> aggregation.

No objection to the ordering.  Since the easy cases are rooted at the  
RIRs and proxy aggregation
would add one to this set, I'm not seeing the big deal.  Also, it  
seems clear that the RIRs are not
appropriate body to reach consensus on routing operational policy, so  
the involvement of
some other organization seems inevitable.

Tony

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Dec 2005 13:06:38 -0500

At 9:27 AM -0800 12/5/05, Tony Li wrote:
>No objection to the ordering.  Since the easy cases are rooted at 
>the RIRs and proxy aggregation
>appropriate body to reach consensus on routing operational policy, 
>so the involvement of

I'd never suggest that the RIRs are involved with routing policy per se.

I suggest that we model address space (and AS #) allocation through 
the registries (RIRs and NIR/LIRs) and via ISPs as a first step. Once 
we have agreement on generating, distributing, and validating 
resource holder credentials, then  we can move onto dealing with 
authorization to originate routes, both directly and in the proxy 
case we've been discussing.

Steve