Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

Randy Bush <> Sun, 05 June 2011 06:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FC7D11E8077 for <>; Sat, 4 Jun 2011 23:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GjIYO58yO1FL for <>; Sat, 4 Jun 2011 23:21:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A79E611E8072 for <>; Sat, 4 Jun 2011 23:21:26 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.76 (FreeBSD)) (envelope-from <>) id 1QT6h0-0003bh-M7; Sun, 05 Jun 2011 06:20:11 +0000
Date: Sun, 05 Jun 2011 06:20:09 +0000
Message-ID: <>
From: Randy Bush <>
To: Joe Touch <>
In-Reply-To: <>
References: <> <> <> <> <> <BANLkTikLi2p7UipJ!> <> <01eb01cc0325$6e4fd260$> <> <033e01cc05a8$0a82f160$> <> <> <017b01cc13ff$0cb6da40$> <> <> <> <> <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Cc: sidr wg list <>
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Jun 2011 06:21:30 -0000

> Yes, servers will support AO, if for no other reason than they support
> BGP and MD5 now.

the problem is that they don't really.  check out, for example, the
freebsd md5 hack.  it is send-only, does not check on receive.  i am
told there are similar messes elsewhere.

basically this is a mess.
  o ipsec is not fully supported to the control plane, and it is
    a masters project to specify compatible parameters.  a sad ietf
  o md5 is not fully supported (on servers), but might be fixed more
    easily than AO.  it is weak in theory and widely deployed and
    deployable in practice.
  o ssh is not fully supported _as a library_ in routers, hacking is
    possible and is being done.
  o AO is nice paperware but does not have significant running code on
    servers or routers.  it tells us something about the ietf to have it
    push so hard on something with so little running code.

which is why we're pretty much using cleartext tcp today.  this is ok
for early deployment.  and it will definitely encourage ops to put the
cache servers close to the routers, which is good :).  but it is not a
good mid-term solution.

we'd really like to see a mandatory-to-implement so that ops have a
clear deployment scenario.  but ssh is the only strong candidate for
that at the moment, and it's not pretty.  at least one router vendor has
implemented.  and we have ssh implementation across a wide variety of

AO is the likely long term mandatory-to-implement, but could be a long
way out on servers.