Re: [RPSEC] FW: AS 8437 announced a quarter of the net for half of an hour

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
"william(at)elan.net" writes:
>  
>  
> On Mon, 14 Aug 2006, Tony Li wrote:
>  
> >> I think Tony's point is that no one should be accepting these.  Almost
> >> all cases of bogus routing that has done damage was accidental.  There
> >> have been some incidents of intentional bogus routes injected as an
> >> attack that I know of but these are (or used to be) far less common.
> >
> > Correct.  The difference between these 'mistakes' and an attack is only
> > one of intent, and a functional security system should render both
> > ineffective.
>  
> Ok. Lets look at this problem then...
>  
> Currently we have proposal being worked on at SIDR WG to provide
> allow verification of routing cryptographic identity. Ultimately
> if deployed we'll have information about all assigned/allocated
> ip blocks.  In such a case if routing announcement comes in and
> it does not have an allocation->routing certificate available then
> a router can discard such an announcement.
>  
> However this is ultimately 20+ years from now (I maybe even a bit
> too optimistic), more likely is that after this begin to get
> deployed, we'll see only few ip blocks that can be cryptographically
> verified. So the questions that come to mind are:
>  
>   1. What happens if an ip block has cryptographic identity in the
>      repository but announcement is smaller then this block?
>        - My current answer is to block it but this may not work
>          since it maybe block for large ISP that has allocated parts
>          to smaller ISPs that did not yet get their routing
>  	announcements signed.

The security mechanism, whatever it is, must be CIDR aware or it is
useless.  For example, attacks were made in the 1990s involving
announcing the blocks containing DNS host addresses for a major
content provider.

>   2. What happens if the announcement is larger then the ip block
>      with cryptographic identity in the repository?
>         - Again I'd prefer to block this but it is always possible
>  	 this maybe an aggregation and its possible that the
>  	 cryptographic identity is for smaller ISP or end-user
>  	 where as larger ISP that ownes ip block has not yet
>  	 deployed the extensions (this is probably impossible
>  	 if we take hierarchical approach with RIRs being root,
>  	 then direct allocation, etc; however my understanding
>  	 is that SIDR does not require hierarchical approach and
>  	 so in practice this maybe possible).

Athentication of smaller address blocks should not allow larger
address blocks to be announced.  Expect to get into arguments over
whether "hostile aggregation" should be allowed.

>   3. What happens if the announcement is from the is space that
>      has not been allocated (such as what happened with AS8437
>      and that started this thread)?
>         - For this I've heard on last WG meeting an idea that
>  	 IANA would sign special CERT stating that no announcements
>  	 would come from the ip block. I don't know how likely
>  	 is it however that IANA would do it and how soon
>  	 (i.e. consider what IANA [has not] done on DNSSEC).

Most of that space is allocated.  If x/8 or anything under x/8 is
protected, then x/8 should not be accepted.  If y/8 is completely
unused, it would be good if the registries made an allocation to
protect it.  In the IRR that is already done.

Another attack that is worth protecting against is announcing a huge
number of very specific routes in unallocated or unprotected addresss
space.  This can exceed memory capacity in routers and cause severe
network problems.  One possible approach is to drop unprotected routes
(no authentication is provided) when too mayy routes are announced,
dropping the most specific routes first.

> Also I don't have a clear idea if SIDR WG would add new extensions
> to BGP or not (if I understood not) like S-BGP was supposed to do.
> Because if it does not happen we can still have cases when ip block
> with proper route in the repository and listed origin AS1 would be
> improperly announced by AS2 with path "AS2 AS1" and this would
> appear to be ok. The only way I see where this can be noticed if
> we have additional attribute as part of BGP route that is actually
> data signed by public key of AS1 (and this should be real-time data
> including timestamp so it could not be replayed).
>  
> -- 
> William Leibzon
> Elan Networks
> [e-mail]

I'm not clear on what SIDR is doing yet but that is my fault, having
only skimmed the internet-drafts so far.

It does seem that they have not taken into consideration many of the
issues that were raised and addressed in the RPS WG.  When I get a
chance I will provide details on the SIDR mailing list.  Sorry if this
seems like inuendo.  I'd like to help with whatever solution the
Internet community decides to pursue so its not intended that way.

Curtis

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