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

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Tue, 15 Aug 2006 09:25:54 -0700

This isn't the real problem. The "real" problem - as it applies to this
scenario - is that SIDR has to develop something that is operationally
simpler to maintain than what we have today. 

The leak would be blocked is you used an ingress filter template (see
http://www.cymru.com/Bogons/index.html). So if the current practice is
too operationally expensive for SPs to deploy and maintain, any thing
that SIDR builds/designs must be better than maintaining filters. This
is a really simple metric to scope out - although difficult to meet.

> -----Original Message-----
> From: william(at)elan.net [mailto:[email-masked]] 
> Sent: Monday, August 14, 2006 9:48 PM
> To: [email-masked]
> Cc: [email-masked]; 'Iljitsch van Beijnum'
> Subject: RE: [RPSEC] FW: AS 8437 announced a quarter of the 
> net for half ofan hour 
> 
> 
> 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.
> 
>   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]
> 
> _______________________________________________
> RPSEC mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rpsec
> 

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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 15 Aug 2006 14:47:50 -0400

In message <[email-masked]>
> is a really simple metric to scope out - although difficult to meet.

Barry,

I agree that the solution has to be simple to administer, better yet
trivial.  The way filters are set today is rather ad-hoc and coverage
is incomplete.

At best we can produce something that requires some work in writing
code of some sort, preferably as little code as possible on routers,
plus minimal work to install or enable, prerferably a code update and
enabling a feature, and as little time as possible to administer.

The "as little time as possible to administer" requirement may be the
most difficult to acheive but it is a requirement.  Another
requirement is that the cost of administering SHOULD fall mostly on
those who benefit.  That is where the IRR had trouble, with those that
didn't use the IRR not wanting to register routes.

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:

> 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: Curtis Villamizar <[email-masked]>
Date: Wed, 16 Aug 2006 09:05:02 -0400

In message <[email-masked]>
> just hire less skilled people and you'll have the same problems as  

Much of the current problems were solved problems in the early 1990s.
To get to most of the Internet you had to go through the NSFNET.  To
get anything through the NSFNET you had to register routes.  The
NSFNET didn't have the types of problems we are now seeing.  The
commercial providers of the time did.

When the NSFNET was decommissioned the requirement to register routes
to get anywhere gradually diminished.  The IRR became ineffective
because certain providers didn't make use of the IRR and so they
refused to register routes.  They regarded use of the IRR as a
competitive advantage for their competitors and they were not going to
do something that helped their competitor.  The big offenders were
Sprintlink and UUNET.

Many providers still resist any form of route registration.  That is
why I made the comment that any administrative cost should be put on
those who benefit because they have the incentive to do the work.  For
example, that might mean building routing databases with both
registered and observed routes rather than just registered routes.

> trouble during the remaining 1% of the time.

Trust me.  I get it.

> in current implementations.

There is lots of room for improvement.  In terms of routing security
most major US corporate users of the Internet (but not all, only 65%
of the fortune 500 were directly connected to the NSFNET when it was
decommissioned in 1995) were better off a decade ago than now.

I'm trying to be realistic given the historic level of cooperation
among Internet providers towards solving this.

Regards,

Curtis

---

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

> commercial providers of the time did.

Yes; but the NFSnet didn't have to maintain filters for 25k ASes and  
several times that number in routes. I don't think generating  
comprehensive filters using current technology is a reasonable  
solution. _Maybe_ if the router vendors implement better ways to get  
the filters into their boxes. But then you still have the issue of  
trusting a database somewhere. In the NFSnet days those weren't all  
that secure. This has gotten better (especially for the RIPE db  
because it's also a registry DB) and will be even better when we have  
certificates in those databases, but I'm still reluctant to have  
filters change on me automatically.

What I thought you meant was better defaults so it's not so  
incredibly easy to leak routes. The default is to propagate, wrong  
filter = leak. With a default that doesn't propagate, all of this  
gets a lot easier, but of course there are still ways to screw that up.

It may even be a good approach to have default "transit", "peer" and  
"customer" classes so that people only have to say what type a link  
is and the filtering happens automatically, at least for those of us  
who don't need more complexity than this.

Iljitsch