Subject: [sidr] SIDR WG Charter question on Security requirements for Proxy Aggregation

From: Geoff Huston <[email-masked]>
Date: Thu, 8 Apr 2010 10:19:04 +1000

> 
> This wording, in effect, leaves the entire issue of proxy aggregation and the associated security credentials that would allow relying parties to be assured of the integrity of the proxy aggregation action to be validated by some to-be-determined mechanism that is not necessarily a ROA. 

I suppose that this observation raises a WG charter question that should be explicitly addressed to the WG Chairs and potentially the Routing ADs:

Given that AS Path is still not within SIDR's charter (due to an on-going lack of clear requirements from the RPSEC WG), what is the status of Proxy Aggregation with respect to the SIDR WG Charter? I personally suspect that it too is outside of the current SIDR charter, as the security requirements for proxy aggregation are not overly clear. Here's what I could find from the last iteration of RPSEC's musings on this topic:

     "Aggregation and de-aggregation: According to RFC4271 [RFC4271], if
      a BGP speaker chooses to aggregate a set of more specific prefixes
      into a less specific prefix then the ATOMIC_AGGREGATE attribute
      SHOULD be set.  This creates a significant challenge for solutions
      to secure BGP because some origination information is removed
      (i.e. the more-specific information which triggered the generation
      of the aggregate).  Proposed solutions MUST indicate how
      aggregation will be accommodated."

It seems to me that the essential requirements for securing proxy aggregation are missing at this stage, which makes it somewhat difficult for SIDR to work on mechanisms without some re-spinning of the SIDR WG Charter (or some other WG) that would permit the preliminary work on security requirements relating to proxy aggregation to come first.

So my question to the WG Co-chairs is: is work on securing  Proxy Aggregation within the current SIDR charter? If so, on what basis?

thanks,

Geoff