|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: BGP certificate insanity was: (DHS insanity - offtopic)
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 [email protected] 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
|