[135851] in North American Network Operators' Group
Re: [arin-announce] ARIN Resource Certification Update
daemon@ATHENA.MIT.EDU (Alex Band)
Sun Jan 30 05:40:27 2011
From: Alex Band <alexb@ripe.net>
Date: Sun, 30 Jan 2011 11:39:36 +0100
In-Reply-To: <23824.1296338405@nsa.vix.com>
To: "nanog@nanog.org list" <nanog@nanog.org>,
Paul Vixie <vixie@isc.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail-86-249196536
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Paul,
I think my question is very pertinent. Of course the number of signed =
prefixes directly influences the number of validators. Do you think the =
RIPE NCC Validator tool would have been downloaded over 100 times in the =
last month if there were only 5 certified prefixes?
In my opinion, the widespread availability of signed prefixes and mature =
validation methods is key to the global success of resource =
certification. I agree that small differences in the size of the set of =
signed routes don't matter on a (relatively) short term, but the reality =
is that the difference would be *enormous* if we wouldn't offer a hosted =
solution.
Practically, in the real world, why would anyone invest time and effort =
in altering their current BGP decision making process to accommodate for =
resource certification if the technology is on nobody's radar, it's hard =
to get your feet wet and there are just a handful of certified prefixes =
out there. Wouldn't it be good if network operators think: "Because it =
helps increase global routing security, it's easy to get started and =
lots of people are already involved, perhaps I should have a look at =
(both sides of) resource certification too."=20
This is why I believe =96 and our adoption numbers prove =96 that the =
entry barrier to the system should be as low as possible, both on the =
signing side and the validation side. Once some of the people that are =
using the hosted platform now decide they would rather run their own =
non-hosted solution at a later stage, that would be even better. That =
immediately solves the private key situation. But there will always be a =
group happy to rely on the hosted model, and we cater to that.
Because of the path we chose there is already a lot of operational =
experience being gained, resulting in a large amount of feedback from a =
wide range of users. This helps us shape the certification system and =
the validator tool, which aids quality and usability. To me, that makes =
a lot of business sense. This is why I think there should be as much =
certified address space available as possible. Otherwise this will stay =
a niche technology until perhaps a major event causes people to wake up =
(and hopefully take action). If certification has reached the necessary =
level of maturity at that point remains to be seen. Furthermore, =
preventing (future) malicious hijacking is not the *only* reason the =
Internet community needs better routing security, the accidental route =
leaking that happens every day is reason enough.
-Alex
On 29 Jan 2011, at 23:00, Paul Vixie wrote:
>> From: Alex Band <alexb@ripe.net>
>> Date: Sat, 29 Jan 2011 16:26:55 +0100
>>=20
>> ... So the question is, if the RIPE NCC would have required everyone
>> to run their own certification setup using the open source tool-sets
>> Randy mentions, would there be this much certified address space now?
>=20
> i don't agree that that question is pertinent. in deployment scenario
> planning i've come up with three alternatives and this question is not
> relevant to any of them. perhaps you know a fourth alternative. here
> are mine.
>=20
> 1. people who receive routes will prefer signed vs. unsigned, and =
other
> people who can sign routes will sign them if it's easy (for example,
> hosted) but not if it's too hard (for example, up/down).
>=20
> 2. same as #1 except people who really care about their routes (like
> banks or asp's) will sign them even if it is hard (for example, =
up/down).
>=20
> 3. people who receive routes will ignore any unsigned routes they =
hear,
> and everyone who can sign routes will sign them no matter how hard it =
is.
>=20
> i do not expect to live long enough to see #3. the difference between =
#1
> and #2 depends on the number of validators not the number of signed =
routes
> (since it's an incentive question). therefore small differences in =
the
> size of the set of signed routes does not matter very much in 2011, =
and
> the risk:benefit profile of hosted vs. up/down still matters far more.
>=20
>> Looking at the depletion of IPv4 address space, it's going to be
>> crucially important to have validatable proof who is the legitimate
>> holder of Internet resources. I fear that by not offering a hosted
>> certification solution, real world adoption rates will rival those of
>> IPv6 and DNSSEC. Can the Internet community afford that?
>=20
> while i am expecting a rise in address piracy following depletion, i =
am
> not expecting #3 (see above) and i think most of the piracy will be of
> fallow or idle address space that will therefore have no competing =
route
> (signed or otherwise). this will become more pronounced as address
> space holders who care about this and worry about this sign their =
routes
> -- the pirates will go after easier prey. so again we see no material
> difference between hosted and up/down on the deployment side or if =
there
> is a difference it is much smaller than the risk:benefit profile
> difference on the provisioning side.
>=20
> in summary, i am excited about RPKI and i've been pushing hard for in
> both my day job and inside the ARIN BoT, but... let's not overstate =
the
> case for it or kneejerk our way into provisioning models whose =
business
> sense has not been closely evaluated. as john curran said, ARIN will
> look to the community for the guideance he needs on this question. i
> hope to see many of you at the upcoming ARIN public policy meeting in
> san juan PR where this is sure to be discussed both at the podium and =
in
> the hallways and bar rooms.
>=20
> Paul Vixie
> Chairman and Chief Scientist, ISC
> Member, ARIN BoT
>=20
>=20
--Apple-Mail-86-249196536
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDrDCCA6gw
ggMRoAMCAQICAgFiMA0GCSqGSIb3DQEBBAUAMIGFMQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9v
cmQtSG9sbGFuZDESMBAGA1UEBxMJQW1zdGVyZGFtMREwDwYDVQQKEwhSSVBFIE5DQzEMMAoGA1UE
CxMDT1BTMQwwCgYDVQQDEwNDQTIxGzAZBgkqhkiG9w0BCQEWDG9wc0ByaXBlLm5ldDAeFw0xMTAx
MTIxMzUxMzZaFw0yMTAxMDkxMzUxMzZaMHgxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1I
b2xsYW5kMREwDwYDVQQKEwhSSVBFIE5DQzELMAkGA1UECxMCVFMxEjAQBgNVBAMTCUFsZXggQmFu
ZDEdMBsGCSqGSIb3DQEJARYOYWxleGJAcmlwZS5uZXQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALC2BQ1PfI/Mbg3yW4hPvFDMxkP+/uATU5b8QRM+dWcrYH7OW7LOFh5UE+oXhmCllp+9Umr8
06HHRC+LtokdHIqTv55GEGERDuQ1CH+67DbzUPisymKXlhOBUkDe5b+Nkm1E4nU40IoWj1r7opA4
iCV5jDY5K+W0E/pbVTyjiGZbAgMBAAGjggExMIIBLTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQf
Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUITctKaBZgfQAULQjw80a
JzbGJHIwgbIGA1UdIwSBqjCBp4AUviRV1EFXFxVsA8ildF9OwyDKY9ihgYukgYgwgYUxCzAJBgNV
BAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xETAPBgNV
BAoTCFJJUEUgTkNDMQwwCgYDVQQLEwNPUFMxDDAKBgNVBAMTA0NBMjEbMBkGCSqGSIb3DQEJARYM
b3BzQHJpcGUubmV0ggEAMB4GA1UdEQQXMBWCE2UzLTIuc2luZ3cucmlwZS5uZXQwDQYJKoZIhvcN
AQEEBQADgYEALLrocn+CoCp4UrtWJQ3i3bzbBfUcAczXK/A+hAq0c34yByLFd1HijR5HnLH/Cusx
UYlvA19wKaknJmNMD+euK48Q3oYHz1xNgUr3y0bvZxshAVc/ShnahPYdADblmqY4Ppv0UT57D0lf
YqBEE5arABTOyI/Bngsq3FBWQX5N36cxggLWMIIC0gIBATCBjDCBhTELMAkGA1UEBhMCTkwxFjAU
BgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTERMA8GA1UEChMIUklQRSBO
Q0MxDDAKBgNVBAsTA09QUzEMMAoGA1UEAxMDQ0EyMRswGQYJKoZIhvcNAQkBFgxvcHNAcmlwZS5u
ZXQCAgFiMAkGBSsOAwIaBQCgggGfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTExMDEzMDEwMzkzNlowIwYJKoZIhvcNAQkEMRYEFCHnA3yKBOnjV3SOe5tBWIyS7uMS
MIGdBgkrBgEEAYI3EAQxgY8wgYwwgYUxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xs
YW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xETAPBgNVBAoTCFJJUEUgTkNDMQwwCgYDVQQLEwNPUFMx
DDAKBgNVBAMTA0NBMjEbMBkGCSqGSIb3DQEJARYMb3BzQHJpcGUubmV0AgIBYjCBnwYLKoZIhvcN
AQkQAgsxgY+ggYwwgYUxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYD
VQQHEwlBbXN0ZXJkYW0xETAPBgNVBAoTCFJJUEUgTkNDMQwwCgYDVQQLEwNPUFMxDDAKBgNVBAMT
A0NBMjEbMBkGCSqGSIb3DQEJARYMb3BzQHJpcGUubmV0AgIBYjANBgkqhkiG9w0BAQEFAASBgJk+
cMopqiBNPD5nGPgA/Ph0szaJndUiSgFy/zF/JFglEoXO/K7evixVTNGWMSgiii87Zqj+kWc+3Cjl
f2xCdwTNYwtnASvrd4BPH2jO9ZGMiVHmXMylj9cX/BJV5fi5G7YoU9lqJdVNceCoW5smRa6UOzJu
6FOPjru+/nHPoD+dAAAAAAAA
--Apple-Mail-86-249196536--
