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

From: "Tony Li" <[email-masked]>
Date: Mon, 14 Aug 2006 12:53:12 -0700

FYI...

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Josh Karlin
> Sent: Monday, August 14, 2006 12:37 PM
> To: [email-masked]
> Subject: AS 8437 announced a quarter of the net for half of an hour
> 
> 
> Greetings,
> 
> Today (Aug 14th 2006) AS 8437 announced 63 /8 nets from 14:30 to 15:00
> UTC.  I don't believe that this is normal, but please correct me if I
> am wrong.
> 
> More info can be found at the Internet Alert Registry here:
> http://cs.unm.edu/~karlinjf/IAR/prefix.php?filter=most
> 
> If you come to this 24 hours of the event, you can go here:
> http://cs.unm.edu/~karlinjf/IAR/search.php and do an Hijacker 
> AS search on 8437.
> 
> If you would like to see the routes as they happened from a RIPE
> viewpoint, please check out this very cool site:
> http://stats.sunet.se/bgpsearch/
> 
> 
> Following is the list of announced nets:
> 
> 1/8
> 2/8
> 5/8
> 7/8
> 23/8
> 27/8
> 31/8
> 36/8
> 37/8
> 39/8
> 42/8
> 49/8
> 50/8
> 77/8
> 78/8
> 79/8
> 92/8
> 93/8
> 94/8
> 95/8
> 96/8
> 97/8
> 98/8
> 99/8
> 100/8
> 101/8
> 102/8
> 103/8
> 104/8
> 105/8
> 106/8
> 107/8
> 108/8
> 109/8
> 110/8
> 111/8
> 112/8
> 113/8
> 114/8
> 115/8
> 116/8
> 117/8
> 118/8
> 119/8
> 120/8
> 173/8
> 174/8
> 175/8
> 176/8
> 177/8
> 178/8
> 179/8
> 180/8
> 181/8
> 182/8
> 183/8
> 184/8
> 185/8
> 186/8
> 187/8
> 197/8
> 198/8
> 223/8
> 

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 15 Aug 2006 00:31:30 +0200

>> UTC.  I don't believe that this is normal, but please correct me if I

Looks like they inject these prefixes into their routers to blacklist  
them (if you route the next hop address to some place unreachable and  
also do a reverse path forwarding check you filter both to and from  
these addresses) but somehow they leaked the prefixes.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 14 Aug 2006 22:00:24 -0400

In message <[email-masked]>
> these addresses) but somehow they leaked the prefixes.

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.

Curtis

---

From: "Tony Li" <[email-masked]>
Date: Mon, 14 Aug 2006 21:06:54 -0700

> 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.  

Until we as a community converge and move forward, these little presents
from the Oort cloud will continue.

Tony

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 14 Aug 2006 21:48:09 -0700 (PDT)

> one of intent, and a functional security system should render both

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.

  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).

  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).

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
[email-masked]

---

From: "Tony Li" <[email-masked]>
Date: Mon, 14 Aug 2006 22:00:57 -0700

William,

If the solution is done correctly, the announcements would not only be
unsigned, but they clearly would conflict with existing signed
advertisements, and would lack the authorization of address space
delegation to the origin.  The bogon announcements would, in all
likelihood be rejected on two grounds.  

This is a benefit to the authorized prefix holder and advertiser of
signed prefixes.  This then acts as further motivation for prefix
holders to actually deploy the solution and get their own prefixes
signed.  It is exactly this property that will encourage widespread
deployment of a solution.  If only we could agree on one...

Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 15 Aug 2006 11:35:37 -0400

In message <[email-masked]>
>          to smaller ISPs that did not yet get their routing

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.

>  	 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.

>  	 (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.

> including timestamp so it could not be replayed).

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Aug 2006 11:22:53 +0200

On 15-aug-2006, at 20:47, Curtis Villamizar wrote:

> I agree that the solution has to be simple to administer, better yet
> trivial.

I disagree. This is a race to the bottom you can't win: business will  
just hire less skilled people and you'll have the same problems as  
before.

The problem with idr administration isn't making it run 99% of the  
time, but doing something during 99% of the time that minimizes the  
trouble during the remaining 1% of the time.

> The way filters are set today is rather ad-hoc and coverage
> is incomplete.

Right; the above is not to say that there isn't room for improvement  
in current implementations.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Aug 2006 11:57:40 +0200

>> one of intent, and a functional security system should render both

Yes, hopefully it will do that. But then we also have the opportunity  
to have problems with the security subsystem, which only allows us to  
differentiate between known-to-be-good routing information and not- 
(know-to-be-good) routing information, which includes both good  
information for which we can't prove that it's good and bad  
information. Unfortunately, we can't tell the difference between  
those sets. This may have the effect of seeing more failures when  
running secured than when running insecure.

> However this is ultimately 20+ years from now

I never understand how people can claim that something internet- 
related will take a certain number of decades. How can you possibly  
look ahead more than, say, five years? And things can happen fairly  
quickly. 20 years ago the total bandwidth of the entire internet was  
probably lower than that of my current home network. So a lot can  
happen in 20 years, and by extension, a lot can happen in fewer years.

>         to smaller ISPs that did not yet get their routing

Hm, I don't know how the current proposals handle it, but I _think_  
it's possible to further delegate sub-prefixes.

But this introduces an interesting new dynamic: today, it's very hard  
to "see" the RIR allocation sizes and filter accordingly in IPv4, but  
when all this info is available in the prefix/AS attestations this  
becomes a lot easier, so people will probably be able to start  
filtering on RIR boundaries or only a small number of extra bits, to  
the delight of some people and the horror of some others.

> 	 so in practice this maybe possible).

Well, obviously if an ISP holds the larger block then they should be  
able to advertise the aggregate. But two other cases are more  
interestinmework v752.2)
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [RPSEC] FW: AS 8437 announced a quarter of the net for half of an
	hour 
Date: Wed, 16 Aug 2006 11:57:40 +0200
To: "william(at)elan.net" <[email-masked]>
Cc: [email-masked]

>> one of intent, and a functional security system should render both

Yes, hopefully it will do that. But then we also have the opportunity  
to have problems with the security subsystem, which only allows us to  
differentiate between known-to-be-good routing information and not- 
(know-to-be-good) routing information, which includes both good  
information for which we can't prove that it's good and bad  
information. Unfortunately, we can't tell the difference between  
those sets. This may have the effect of seeing more failures when  
running secured than when running insecure.

> However this is ultimately 20+ years from now

I never understand how people can claim that something internet- 
related will take a certain number of decades. How can you possibly  
look ahead more than, say, five years? And things can happen fairly  
quickly. 20 years ago the total bandwidth of the entire internet was  
probably lower than that of my current home network. So a lot can  
happen in 20 years, and by extension, a lot can happen in fewer years.

>         to smaller ISPs that did not yet get their routing

Hm, I don't know how the current proposals handle it, but I _think_  
it's possible to further delegate sub-prefixes.

But this introduces an interesting new dynamic: today, it's very hard  
to "see" the RIR allocation sizes and filter accordingly in IPv4, but  
when all this info is available in the prefix/AS attestations this  
becomes a lot easier, so people will probably be able to start  
filtering on RIR boundaries or only a small number of extra bits, to  
the delight of some people and the horror of some others.

> 	 so in practice this maybe possible).

Well, obviously if an ISP holds the larger block then they should be  
able to advertise the aggregate. But two other cases are more  
interesting:

- when 10/8 and 11/8 both legitimately come from some origin, should  
that origin not be able to advertise 10/7 instead?

- when someone in the middle, who supposedly legitimately provides  
transit for a set of prefixes, but is not authorized to originate  
them, wants to aggregate this set of prefixes, should that be  
allowed? I think we probably want to have an additional layer of  
authorization for that, so that people can decide whether they accept  
this or not. For instance, I may want my ISP to aggregate a bunch of  
stuff for me, but I wouldn't want my peers to do the same.

> 	 would come from the ip block.

Well, if you only accept secure routing information, this isn't a  
problem because the dark space will fail the security checks. But it  
will probably be a long time before it's safe to completely reject  
routing information that fails the security checks, so this isn't all  
that helpful.

Obviously it's fairly easy to mark unused /8s "unused" because there  
is a reasonable amount of time between the moment those are given to  
a RIR and the moment the address space shows up in BGP. But this is  
harder for blocks of address space the RIRs are actively using for  
allocations/assignments, as those happen every day and more than a  
day or two as a minimum between allocation and use isn't acceptable.

For mistakes such as this one that doesn't matter, but if we want to  
have protection against address space hijacking for stuff like  
fishing and big spam runs it's important to not leave any cracks  
because this only takes a very small amount of address space (/24 or  
so).

> to BGP or not

As opposed to...?

Building a new idr protocol that should replace BGP over time, or  
taking the whole thing out of band?

> including timestamp so it could not be replayed).

I see three problems with that:

1. Having private keys (with inter-AS significance) in routers makes  
me profoundly uncomfortable because those keys can be stolen when the  
router is compromised either over the network or physically

2. The additional storage requirements for BGP tables

3. The fact that BGP works per-prefix rather than per-AS means that  
doing per-AS work gives you O(prefixes * average AS path length)  
rather than O(ASes) which is in the neighborhood of O(700,000) vs O 
(25,000)

One solution to this is acknowledge the operational reality that for  
any AS path, one part is trusted by the origin and the remaining part  
is trusted by the receiver of the routing information. So if the  
origin lists all the ASes that it trusts, and the receiver knows all  
the ASes that it trusts, an AS path should only consist of a subset  
of the combination of those sets of ASes.

For a very different approach (to inter-domain routing in general,  
not just idr security), have a look at http://www.ietf.org/internet- 
drafts/draft-van-beijnum-idle-00.txt

g:

- when 10/8 and 11/8 both legitimately come from some origin, should  
that origin not be able to advertise 10/7 instead?

- when someone in the middle, who supposedly legitimately provides  
transit for a set of prefixes, but is not authorized to originate  
them, wants to aggregate this set of prefixes, should that be  
allowed? I think we probably want to have an additional layer of  
authorization for that, so that people can decide whether they accept  
this or not. For instance, I may want my ISP to aggregate a bunch of  
stuff for me, but I wouldn't want my peers to do the same.

> 	 would come from the ip block.

Well, if you only accept secure routing information, this isn't a  
problem because the dark space will fail the security checks. But it  
will probably be a long time before it's safe to completely reject  
routing information that fails the security checks, so this isn't all  
that helpful.

Obviously it's fairly easy to mark unused /8s "unused" because there  
is a reasonable amount of time between the moment those are given to  
a RIR and the moment the address space shows up in BGP. But this is  
harder for blocks of address space the RIRs are actively using for  
allocations/assignments, as those happen every day and more than a  
day or two as a minimum between allocation and use isn't acceptable.

For mistakes such as this one that doesn't matter, but if we want to  
have protection against address space hijacking for stuff like  
fishing and big spam runs it's important to not leave any cracks  
because this only takes a very small amount of address space (/24 or  
so).

> to BGP or not

As opposed to...?

Building a new idr protocol that should replace BGP over time, or  
taking the whole thing out of band?

> including timestamp so it could not be replayed).

I see three problems with that:

1. Having private keys (with inter-AS significance) in routers makes  
me profoundly uncomfortable because those keys can be stolen when the  
router is compromised either over the network or physically

2. The additional storage requirements for BGP tables

3. The fact that BGP works per-prefix rather than per-AS means that  
doing per-AS work gives you O(prefixes * average AS path length)  
rather than O(ASes) which is in the neighborhood of O(700,000) vs O 
(25,000)

One solution to this is acknowledge the operational reality that for  
any AS path, one part is trusted by the origin and the remaining part  
is trusted by the receiver of the routing information. So if the  
origin lists all the ASes that it trusts, and the receiver knows all  
the ASes that it trusts, an AS path should only consist of a subset  
of the combination of those sets of ASes.

For a very different approach (to inter-domain routing in general,  
not just idr security), have a look at http://www.ietf.org/internet- 
drafts/draft-van-beijnum-idle-00.txt