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

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:william@elan.net] 
> Sent: Monday, August 14, 2006 9:48 PM
> To: tony.li@tony.li
> Cc: rpsec@ietf.org; '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
> william@elan.net
> 
> _______________________________________________
> RPSEC mailing list
> RPSEC@ietf.org
> https://www1.ietf.org/mailman/listinfo/rpsec
> 

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec