RE: BGP certificate insanity was: (DHS insanity - offtopic)

["Chris L. Morrow" <christopher.morrow () verizonbusiness com>]

I think a backup and level-set is in order... The original comment that
started this discussion was talking about ONLY signing allocations down
from IANA->RIR->LIR->EndSite, only in the whois system and NOT for use in
routing devices.

The papers/preso's that Sandy pointed to all talk only about using
cert-material to help figure out who really is the owner of the space and
use that knowledge to update prefix-list/policy in the field. Randy's
preso at:

http://www.nanog.org/mtg-0602/pdf/bush.pdf

has a very clear walk through of this (and nice font too... but that's
beside the point).

So, all FUD about 'certs on routes in bgp' aside (which is the mission of
sBGP/soBGP and NOT the mission of the discussion so far) is there a real
issue with giving operators a way to see, in a programmatic and simple
fashion, if there's little overhead/cost on the system (whois system) as
a whole?

...a little more below...

On Tue, 24 Apr 2007 michael.dillon () bt com wrote:

> > How can anybody be sure that the random peering tech they are
> > talking
> > to really works for the organisation listed in the whois record? By
> > visual inspection of the e-mail address?
>
> Do people really talk to random peering techs? I thought that peering
> contacts were all set up via face-to-face meetings. In any case, if it
> is email authentication that you are after, putting certificates in your
> router will not help you.

The scenario I worry about isn't the 'peering tech' (mostly because I
don't know any aside from Sri...) it's the 'random customer' who calls in
or emails in and 'needs this prefix change quickly, something got screwy
and we need you to accept this post-haste!' (insert 'millions of
dollars/sec lost!' conversation and escalation to
senior-exec-management... yes, this is a real-life example)

Those cases are painful and we have no method of knowing easily who the
'customer' is and who the 'ip owner' (user/end-site) is and if there is
proper LOA in place :( Making a simple shell script to do 5 whois lookups
and 3 openssl cert checks seems like a 'big win', eh?

> Also, normal business practices can be very useful to establish the
> identity of people. For instance, call the company where said peering
> tech works, and ask for their extension. If you can't reach them by
> phone, then tell them that you need to discuss the matter with their
> boss. Everybody has a boss and should be willing to identify the boss by
> name. Then phone the company and ask for the boss by name. If there is
> still no luck, then you know that your leg is being pulled.

call my office I'll get our president on the phone with you.. pardon his
voice though, he's got a little bit of a cold :( Is this really something
you'd trust in the real world? If so, could you route: 209.173.48.0/20 for
me?

> > A faxed LOA on company
> > letterhead?
>
> A lot of people do require LOAs on company letterhead to begin peering
> but I'm not sure faxed documents are good enough. In addition, a lot of
they are not good enough :( you wouldn't imagine the word-template-crap we
get as LOA from obvious scammer/spammer/bad-peeps :( it's sad really.

> companies define the contact points in the peering agreeements so you
> know who is who at the other side and how to reach them (direct dial
> phone numbers). There is also INOC-DBA where somebody else has done some
> level of authentication of people at your peers.

peering is a whole-nuther-land ... customer prefix attestation/ajudication
is where the real rubber hits the road (for me atleast).

> In other words, there are lots of reasonable ways to solve this problem
> without having to put the complexity and load of crypto on your routers.

correct, here we agree... We may be a minority, but :)

-Chris