Re: [rrg] RRG to hibernation

Tony Li <> Sat, 10 November 2012 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DF9F21F84AE for <>; Sat, 10 Nov 2012 09:54:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.437
X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r2ZVyxagd5YL for <>; Sat, 10 Nov 2012 09:54:40 -0800 (PST)
Received: from ( [IPv6:2001:558:fe2d:43:76:96:30:16]) by (Postfix) with ESMTP id 4107021F849B for <>; Sat, 10 Nov 2012 09:54:39 -0800 (PST)
Received: from ([]) by with comcast id Mqkr1k0061smiN4A1tuftz; Sat, 10 Nov 2012 17:54:39 +0000
Received: from [] ([]) by with comcast id Mtud1k00P43ZcXW8gtue7k; Sat, 10 Nov 2012 17:54:39 +0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Tony Li <>
In-Reply-To: <>
Date: Sat, 10 Nov 2012 09:54:37 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Danny McPherson <>
X-Mailer: Apple Mail (2.1499)
Cc:, Noel Chiappa <>
Subject: Re: [rrg] RRG to hibernation
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 10 Nov 2012 17:54:40 -0000

>> I agree that some security needs to be deployed.  I'm not convinced that it needs to be BGPSEC.  We've muddled along for many years and never found the gumption to actually deploy anything.  Must not be important to people.  I don't get it, but that's the observable behavior.  
>> In any case, this doesn't seem like a research topic.  This is pretty clearly an engineering issue.
> I don't agree.  The engineering solution that SIDR is actively working (RPKI-enabled BGPSEC) is pumping out standards track RFCs like there's no tomorrow.  The USG has stated intentions of "expediting secure routing work through the Internet standard process" and "fostering adoption through government procurement vehicles".  
> As an operator this scares the hell out of me, especially considering what they've designed is largely a system to control "what's routed on the Internet and by whom".  They can't seem to do anything in BGP(SEC) without introducing the equivalent of "periodic updates", and undoing all the goodness of things like update packing completely.  
> Some serious thinkers working on this problem would be goodness…

I agree, but as you correctly point out, SIDR is an engineering solution.  If you dislike that particular solution, you're of course free to propose others.  However, the correct forum for engineering solutions is the IETF.