Carl Malamud: Internet Talk Radio, flame of the Internet. 


Malamud: This is Geek of the Week. We’re talk­ing to Phil Karn, who’s a staff engi­neer at Qualcomm Inc. Welcome to Geek of the Week, Phil

Phil Karn: Thanks Carl.

Malamud: You’re per­haps best known in the Internet as the author of KA9Q. Why don’t you tell us what KA9Q is?

Karn: Okay well, first of all, KA9Q was actu­al­ly my ama­teur radio call, my ham radio call sign. I’ve been a radio ama­teur since I was in high school. It’s uh, been some time now. But that name has got­ten applied to a pack­age of soft­ware I wrote pri­mar­i­ly for ama­teur pack­et radio use. It does TCP/IP under DOS machines. However it has found quite a fol­low­ing beyond ama­teur radio. And a lot of are peo­ple run­ning it who have noth­ing to do with ama­teur radio.

Malamud: So this is a pub­lic domain TCP/IP implementation?

Karn: Well, qua­si pub­lic domain. It’s…

Malamud: Freely available.

Karn: Freely avail­able, yes. I encour­age for use by any­one in an aca­d­e­m­ic set­ting or ama­teur radio set­ting. It’s kin­da share­ware in oth­er envi­ron­ments, and any­one who wants to put it into a prod­uct should come talk to me. It’s been the basis of a num­ber of com­mer­cial prod­ucts such as the Telebit NetBlazer, the Rockwell CMC NetHopper, and the NEC Dr. BonD, are all based on licensed copies of KA9Q.

Malamud: So this is soft­ware you can just FTP down turn a PC into a router?

Karn: Yes. Yes. It’s more than just a router. The sys­tem is an exe­cutable file which you exe­cutes on DOS, and it acts as an IP router with mul­ti­ple inter­faces includ­ing ama­teur pack­et radio, which you know, reflects its ori­gins. And it also has the stan­dard Internet ser­vices and clients. There’s a tel­net client, an FTP client, an FTP serv­er, a mail serv­er, and so forth.

Malamud: When we think of TCP/IP we think of Ethernet, we think of 300 or 1200 or 9600 BPS modems. We don’t nec­es­sar­i­ly think of ama­teur radio. How does TCP/IP work in that environment?

Karn: It works. Not fast by any­body’s stan­dard. But it does work, and in fact some of the ear­ly exper­i­ments in run­ning TCP/IP over ama­teur radio pro­duced per­for­mance enhance­ments which lat­er got fed back into the TCP spec.

Malamud: For example.

Karn: Well, for exam­ple there’s an algo­rithm that I invent­ed about sev­er­al years into the project which calls for fil­ter­ing of round-trip times, based on whether or not a pack­et had been retrans­mit­ted. There’s this prob­lem in TCP that if you retrans­mit a pack­et more than once— Or you send a pack­et more than once, oth­er­wise you would retrans­mit it, and then an acknowl­edg­ment comes back, you don’t know whether the acknowl­edg­ment was for the first trans­mis­sion of that pack­et, or for a lat­er trans­mis­sion of that pack­et. In oth­er words you don’t know whether the pack­et was lost or whether the net­work was sim­ply slow in respond­ing. So you have to be care­ful in mea­sur­ing such round-trip times and incor­po­rate them into your esti­mate of the round-trip time, oth­er­wise TCP will per­form very bad­ly. So I came up with an algo­rithm for deal­ing with that in the pack­et radio envi­ron­ment, where it was real­ly a crit­i­cal prob­lem. And it has since gone back into the TCP spec.

Malamud: Now, your ear­ly work on pack­et radio has I guess come back to haunt you now that you’re work­ing at Qualcomm. You’re work­ing on wire­less data communications?

Karn: Right. Now I get to do it for real.

Malamud: And what kind of work are you look­ing at now?

Karn: Okay. Qualcomm is a com­pa­ny— It’s been around since 1985, it’s grown very very rapid­ly, espe­cial­ly in the last few years. We’re now well over a thou­sand employ­ees. We’re based in San Diego although have a pres­ence and in Boulder, Colorado. And our pri­ma­ry activ­i­ty, or Qualcomm’s field of activ­i­ty is radio com­mu­ni­ca­tion ser­vices, par­tic­u­lar­ly spread-spectrum, com­mer­cial appli­ca­tions of spread spec­trum. We have a ser­vice that we sell— It’s been extreme­ly pop­u­lar, it’s grow­ing very fast. I like to say that it’s grow­ing about as fast as the Internet, dou­bling about once every year—a lit­tle over a year. It’s a ser­vice called Omnitracs and it’s primarily—or it could be best described as satel­lite email for truck­ers. We just recent­ly sold our 60,000th unit. The sys­tem con­sists of a satel­lite ter­mi­nal, a Ku band satel­lite ter­mi­nal that sits on a truck, and a hub in San Diego. And from San Diego at Qualcomm we have lines, VSAT links, tele­phone lines, pack­et links and so forth, back to var­i­ous truck­ing com­pa­ny dis­patch­ers so that they keep track of their trucks while they’re on the road.

So that’s Qualcomm’s pri­ma­ry source of rev­enue right now. And we’ve been feed­ing a lot of that mon­ey back into what we call the CDMA dig­i­tal cel­lu­lar project. CDMA is actu­al­ly a gener­ic term, it stands for Code-Division Multiple Access. It’s a form of spread spec­trum where sev­er­al trans­mit­ters can share the same fre­quen­cy band at the same time in the same area by use of dif­fer­ent spread­ing codes. So we have applied CDMA tech­niques to the devel­op­ment of a new dig­i­tal cel­lu­lar tele­phone sys­tem which we also call CDMA. And that was recent­ly stan­dard­ized with­in United States as sec­ond dig­i­tal cel­lu­lar tele­phone system.

My role in this project is pri­mar­i­ly to bring up data ser­vices over CDMA. I’ve had TCP/IP run­ning over CDMA for about the last year. And in fact it’s based on the KA9Q NOS soft­ware pack­age, with nec­es­sary addi­tions to sup­port CDMA.

Malamud: What kind of band­width are we’re look­ing at here?

Karn: The CDMA chan­nel was orig­i­nal­ly devel­oped for a low-bitrate voice encoder, a variable-rate voice encoder, using a mod­i­fied code­book inside a lin­ear pre­dic­tor, a SELP vocoder. The max­i­mum rate is approx­i­mate­ly 8,000 bits per sec­ond, in round num­bers. Again that’s based on the char­ac­ter­is­tics of the vocoder; data was sec­ondary. So, the through­put that you can get when you run TCP/IP over a CDMA chan­nel, with all the pro­to­col over­heads and so forth tak­en out, is rough­ly 900 to 950 char­ac­ters per sec­ond, depend­ing on conditions.

Malamud: And how does this com­pare let’s say to RAM Mobile Data, or some of the oth­er data services?

Karn: It’s quite a bit faster than RAM Mobile, but just look­ing raw speed is some­what decep­tive. What’s real­ly impor­tant is what’s the reli­a­bil­i­ty. If you drop half the pack­ets, it does­n’t mat­ter that it’s fast because TCP will always be you know, tim­ing out and back­ing off and retransmitting—your over­all through­put will be very poor.

The RAM Mobile sys­tem’s based on nar­row­band tech­nol­o­gy, that is the CDPD tech­nol­o­gy, the Cellular Digital Packet Data. And they don’t per­form near­ly as well in urban mul­ti­path envi­ron­ments as does CDMA

So our sys­tem, the fig­ure I give you for our sys­tem is some­thing that just works. As long as I can keep a call up that’s what you get. The data just keeps flow­ing. It’s much hard­er to get a fig­ure for RAM Mobile or for CDPD…well, because they’ve only been tested…uh…back up on this one. 

RAM Mobile and CDPD have been based on nar­row­band tech­nol­o­gy, and they have not been heav­i­ly test­ed in dense urban envi­ron­ments, unlike our sys­tem which has been test­ed very exten­sive­ly in San Diego.

Malamud: Are there dif­fer­ences in range, in num­ber of cells you need, the amount of equip­ment you need in order to pro­vide nation­wide coverage?

Karn: There’s some of that. All these are ter­res­tri­al UHF sys­tems, so they all basi­cal­ly are lim­it­ed to line of sight with­in a ter­res­tri­al area—line of sight on near line of sight paths with­in a met­ro­pol­i­tan area. So they’re all sim­i­lar in that regard. CDMA is sim­ply much bet­ter at deal­ing with mul­ti­path, which is sig­nals reflect­ing off of build­ings and com­bin­ing at the receiv­er. In most radio sys­tems, includ­ing exist­ing ana­log cel­lu­lar, CDPD, and RAM Mobile, mul­ti­path seri­ous­ly degrades per­for­mance. However in CDMA, mul­ti­path a actu­al­ly a help. It’s actu­al­ly some­thing we export­ed to improve the reli­a­bil­i­ty of the sig­nal path.

So, there has not yet been any wide­spread deploy­ment CDPD so we don’t real­ly know how well that will per­form in the real world. RAM Mobile is out there. I don’t want to speak for them. I’ve only seen it demon­strat­ed at Interop, and I’ve seen peo­ple using PSI’s mail ser­vices based on RAM Mobile but I don’t have any per­son­al expe­ri­ence with it myself so I can’t speak for them.


Malamud: We’re look­ing at a vari­ety of very large projects which are not terrestrial-based. Things like Motorola’s LEO sys­tem, low Earth orbit­ing satel­lites. How does that com­pare to the type of data ser­vices that you’re look­ing at?

Karn: Okay. I’m glad you men­tioned low Earth orbit­ing satel­lites since Qualcomm has a low Earth orbit­ing satel­lite project of its own called Globalstar. The idea is some­what sim­i­lar on the face of it to Iridium, which is a net­work of low Earth orbit­ing satel­lites. However the dif­fer­ences are that in the Globalstar sys­tem the satel­lites are much sim­pler. They’re basi­cal­ly what are called bent pipes. In oth­er words there’s real­ly no active pro­cess­ing of the sig­nal on-board, it sim­ply repeats what it hears. The idea is that the satel­lite would sim­ply act as a repeater between a user sta­tion and a rel­a­tive­ly near­by ground sta­tion, which would actu­al­ly be your gate­way into the net­work. There would not be any cross-satellite link­ing, unlike Iridium.

So this would be exact­ly the same mod­u­la­tion method and ser­vices that this ter­res­tri­al CDMA sys­tem would sup­port, except it would be on dif­fer­ent fre­quen­cy bands and be going through a satel­lite rather than direct­ly to a base station. 

Malamud: A com­pli­men­ta­ry area is the work for Mobile IP, in which peo­ple are look­ing at the abil­i­ty to get in a car and move from one sub­net­work to anoth­er sub­net­work and still keep the appli­ca­tions alive, still keep your tel­net ses­sion or your email or what­ev­er it is that you’re doing. What’s the rela­tion­ship between the work that you’re doing with radio-based data links and the Mobile IP efforts that’re on the way.

Karn: I am per­son­al­ly very inter­est­ed in Mobile IP. It’s one the rea­sons I’m still involved in IETF, along with some of the secu­ri­ty issues which also come up when doing net­work­ing over radio. Mobile IP I see as being cru­cial to the future of these data radio services. 

In the begin­ning, these ser­vices are going to be fair­ly sim­ple, just as cel­lu­lar radio was in the begin­ning. But as time goes on peo­ple are going to demand the abil­i­ty to pick up a lap­top and move around with them from one envi­ron­ment to anoth­er, one media to anoth­er, and have trans­par­ent con­nec­tiv­i­ty, the only dif­fer­ence being speed and cost.

Malamud: Do we have any indi­ca­tion how we’re gonna do that? I know we don’t have final answers but do we at least see the road?

Karn: Oh, yeah. Yes. I think so. I can’t speak for the Mobile IP group as a whole. I’m not the chair­man or part of the man­age­ment of that group. But I think the only prob­lem with the Mobile IP group right now is com­ing down to a con­sen­sus on one approach. Everyone has an approach which looks pret­ty much the same. Everyone has pret­ty much the same phi­los­o­phy. What we real­ly need to do is just get agree­ment on one com­mon approach. I think that was facil­i­tat­ed a few months ago by the deci­sion to start with a very sim­ple ser­vice, not try­ing to opti­mize it to the nth degree but to start with a sim­ple ser­vice and then deploy that, mak­ing sure that we don’t pre­clude opti­miza­tions and new ser­vices or fea­tures that could be added later.

Malamud: What are some of the broad brush… What’s a broad brush char­ac­ter­i­za­tion of how we’re going to do Mobile IP? I know we don’t know all the details but we know [crosstalk] at least some of the ideas.

Karn: Okay. The basic prin­ci­ple of Mobile IP is the fol­low­ing: because the Internet is a con­nec­tion­less net­work, I could go any­where in that net­work and send a pack­et to a fixed host and it would get there. That’s not a prob­lem because the routers in the net­work don’t real­ly look at the source address in my packed so I could be any­where. The prob­lem how­ev­er is how does a fixed host in the net­work get pack­ets back to me if I’m mov­ing around. The Internet is based on a hier­ar­chi­cal rout­ing mod­el where the routers in the back­bone do not have every sin­gle host in the net­work list­ed in those tables, that would be infea­si­ble, they have net­works and subnet­works list­ed in that table. So I need to have some mech­a­nism that I can move around and have my pack­ets fol­low me with­out hav­ing to go back and retro­fit every router in the Internet core. 

This is being done by over­lay­ing anoth­er lev­el of hier­ar­chi­cal, so to speak, on the exist­ing Internet using spe­cial­ized routers called home agents and for­eign agents. A home agent would be a router that sits on my home net­work, in oth­er words the same sub­net for which my IP address has been assigned. And the home agent will be respon­si­ble for know­ing the actu­al loca­tion of the mobile at any giv­en time, and then tun­nel­ing pack­ets addressed to that mobile sta­tion to what’s called a for­eign agent on the net­work where the mobile actu­al­ly hap­pens to be at the moment. 

So, pack­ets from the mobile sta­tion to a fixed sta­tion can go direct­ly with no spe­cial han­dling. But pack­ets from fixed sta­tions to mobile sta­tions would have to go through this extra tun­nel­ing step before they can be rout­ed to the mobile station. 

Malamud: And how far away are we from the from see­ing Mobile IP as an inte­gral part of the Internet?

Karn: I can’t real­ly speak to that, I can say that in my own area, if we’re going to pro­vide a mean­ing­ful IP con­nec­tiv­i­ty ser­vice with­in CDMA—and I believe we will, just as CDPD’s core ser­vice is IP by radio, I think it’s going to be essen­tial to have this. So as these sys­tems get deployed, as CDMA and CDPD and oth­er sys­tems like RAM mobile become more pop­u­lar I think this is going to be— [Karn is inter­rupt­ed by music]


Malamud: Phil Karn, as a mem­ber of the tech­ni­cal staff at Bellcore you were heav­i­ly involved in secu­ri­ty, and now that you’re look­ing at wire­less and radio-based solu­tions I would think that secu­ri­ty is becom­ing increas­ing­ly impor­tant to you.

Karn: Yes. It’s crit­i­cal. In fact I think it’s one of these enabling tech­nolo­gies. They would sim­ply be things that peo­ple will not want to do over net­works as eas­i­ly inter­cept­ed as radio with­out some mean­ing­ful secu­ri­ty. In fact I’m sur­prised at how much is done right now over cel­lu­lar tele­phones over total­ly inse­cure chan­nels. If peo­ple only knew how easy it was to inter­cept your tele­phone con­ver­sa­tions, they would not talk about half as many things as they do now. But I think for a data net­work, it’s going to be actu­al­ly cru­cial that we have some strong security.

Malamud: And so that would be the Clipper chip?

Karn: Absolutely not. That’s a whole sub­ject in itself. I’m strong­ly opposed to Clipper or any notion of key escrow. I want—

Malamud: Could you describe briefly what it is about Clipper that you don’t like? What are they doing in Clipper that is so objectionable?

Karn: There are many rea­sons both prac­ti­cal and polit­i­cal as to why Clipper is a bad idea. I mean first of all, I don’t see any rea­son why I should be required to have my keys reg­is­tered ahead of time and be told that I should sim­ply trust the gov­ern­ment that they will nev­er vio­late my pri­va­cy with­out good cause. There’s ample of pres­i­dent over his­to­ry to show that the gov­ern­ment always abus­es that kind of pow­er. And I sim­ply don’t think it’s appro­pri­ate in a free society. 

But there are many prac­ti­cal prob­lems also asso­ci­at­ed with the clip­per chip. For exam­ple in my indus­try, in cel­lu­lar tele­pho­ny, low cost and high vol­ume are the watch­words. And it’s sim­ply not prac­ti­cal to take a device such as a hand-held cel­lu­lar tele­phone and man­date that a sole-sourced hard­ware chip be put into this phone to do a func­tion which could very eas­i­ly be done in soft­ware with the spare cycles on the general-purpose proces­sors already in that ship. So for all sorts of prac­ti­cal and philo­soph­i­cal rea­sons Clipper is sim­ply a no-brainer. It is not going to get off the ground.

Malamud: Are there bet­ter ways of doing it?

Karn: Absolutely. In the real world, in the com­mer­cial world, we actu­al­ly have plen­ty of usable tech­niques that we sim­ply have to deploy. And if the gov­ern­ment have not been stand­ing in our way all along we would’ve deployed them by now. I’ve had some expe­ri­ence with this in watch­ing the stan­dards process with­in the dig­i­tal cel­lu­lar com­mu­ni­ty and I saw the sub­tle pres­sures that the NSA exert­ed on the dig­i­tal cel­lu­lar indus­try to not put in mean­ing­ful pri­va­cy. If those pres­sures had not been there we prob­a­bly would have it by now.

Malamud: So what would be mean­ing­ful pri­va­cy? What would be the tech­niques you would use?

Karn: Meaningful pri­va­cy in a dig­i­tal cel­lu­lar phone would mean end-to-end encryp­tion or at least as end-to-end as you can make it. For a nor­mal cel­lu­lar user talk­ing to an ordi­nary land tele­phone you would not be able to do true end-to-end encryp­tion but you could at least pro­tect the most vul­ner­a­ble part of the link, which is the air link. That is the link between the cel­lu­lar phone and the base sta­tion. The call over the land­line por­tion would still of course be in the clear. That could be done right now using off-the-shelf tech­nol­o­gy. It’s sim­ply not a prob­lem. I would use some com­bi­na­tion of RSA pub­lic key cryp­tog­ra­phy, Diffie-Hellman key exchange, and a good cipher imple­ment­ed in the soft­ware, be it [indis­tinct] DES or mul­ti­ple— [Karn is inter­rupt­ed by music]


Malamud: RSA is a tech­nol­o­gy that’s wide­ly acknowl­edged as being one of the strongest meth­ods we have of secur­ing our data and doing authen­ti­ca­tion and doing authen­ti­ca­tion and many of the oth­er secu­ri­ty aspects, but it’s tak­en a long time to get that out in the field. Do you have any ideas as to why we don’t have a kind of mas­sive ubiq­ui­tous pub­lic key infra­struc­ture in place?

Karn: Well we’re actu­al­ly start­ing at one now, as much as the com­pa­ny that owns the RSA patent would­n’t like to admit it’s, called PGP. That touch­es on what I per­son­al­ly think is the main rea­son why RSA has not become wide­spread. It’s because of the intel­lec­tu­al prop­er­ty issues. That com­bined with the fact that most peo­ple would rather bury their heads in sand about secu­ri­ty or are not real­ly will­ing to go out of the way to get it, I think those fac­tors com­bined have result­ed in RSA being not wide­ly deployed.

Malamud: Well tell us about PGP. What is that?

Karn: PGP is Pretty Good Privacy. It’s a soft­ware pack­age that was orig­i­nal­ly done by Phil Zimmerman in Boulder, Colorado as sort of a social state­ment. He wrote it as a free­ware pack­age and then gave it away, and it has since become very wide­spread all over the world.

Malamud: And is it based on RSA’s technology?

Karn: It’s a hybrid cryp­to sys­tem, which is what most appli­ca­tions of RSA are. For very prac­ti­cal rea­sons you do not actu­al­ly encrypt your data with RSA, you’re gen­er­al­ly com­bin­ing with a con­ven­tion­al sym­met­ric cipher, that is a cipher that uses the same key for encryp­tion and decryp­tion. And then you use RSA to man­age the keys for that sym­met­ric encryp­tion sys­tem. And PGP is an exam­ple of such a sys­tem. When I send a mes­sage to you in PGP, I will first encrypt that mes­sage using a con­ven­tion­al cipher called IDEA which came out of Europe a few years ago. And then I’ll take the randomly-generated keys that I used to encrypt with IDEA, encrypt that using RSA using your pub­lic key, and then put that on the front of the mes­sage and send it to you. That’s a stan­dard, accept­ed tech­nique for apply­ing RSA in real systems. 

Malamud: And PGP is being used.

Karn: PGP is being used world­wide. At the last count, the pub­lic key servers out on the net had over 2,000 keys reg­is­tered, and it is grow­ing daily.

Malamud: Are there intel­lec­tu­al prop­er­ty issues? Has this vio­lat­ed RSA right to their work?

Karn: I’m not a lawyer, I can’t com­ment on that. I can say that it’s been a con­tro­ver­sial top­ic for sev­er­al rea­sons. One is the intel­lec­tu­al prop­er­ty rea­sons. RSA claims that this vio­lates their patents, how­ev­er I can’t real­ly talk to that because I’m not a lawyer. 

The oth­er issue is export con­trols. Our gov­ern­ment still seem to think that only Americans know how to write C code from an algo­rithm descrip­tion, which is of course bla­tant­ly idi­ot­ic. Nevertheless PGP has found its way out of the coun­try. And as I under­stand it there’s cur­rent­ly a fed­er­al inves­ti­ga­tion in exact­ly how that happened.

Malamud: Are there ways that we can get that tech­nol­o­gy out of the cur­rent sit­u­a­tion in which one com­pa­ny has it and there’s peo­ple out there with their own ver­sions like PGP? I mean should should RSA patents be nation­al­ized, for example?

Karn: Well… We’re get­ting into an area where I’m not real­ly qual­i­fied to com­ment. I mean, I have my own per­son­al opin­ions but they’re just that, just opinions.

Malamud: How impor­tant is the RSA pub­lic key tech­nol­o­gy to the Internet?

Karn: I think it’s vital. If we’re going to do mean­ing­ful secu­ri­ty of any kind in a pub­lic con­text, some form of pub­lic key cryp­tog­ra­phy is absolute­ly essen­tial. Not just RSA but Diffie-Hellman. Diffie-Hellman has not got­ten as much atten­tion as I think it should have because it’s an excel­lent way for dis­trib­ut­ing keys. For exam­ple in the secure IP are­na, which I’m also work­ing in, there’s real­ly no prac­ti­cal way to dis­trib­ute keys between arbi­trary pairs of hosts oth­er than through the use of pub­lic key cryptography. 

Malamud: And why don’t we use Diffie-Hellman? Is that pub­licly available?

Karn: Diffie-Hellman is also pro­tect­ed by a patent, which is held by the same folks that hold the RSA patent, which is Public Key Partners in California.

Malamud: So there’s no way out.

Karn: There’s basi­cal­ly no way out when it comes to pub­lic key, that’s right. We have to deal with Public Key Partners. 

Malamud: Now, with pub­lic key we’re look­ing at the abil­i­ty to basi­cal­ly authen­ti­cate who is com­ing in—

Karn: That’s the com­ple­men­tary side to con­fi­den­tial­i­ty. There are two aspect to cryp­to­graph­ic secu­ri­ty. One is con­fi­den­tial­i­ty, in oth­er words keep­ing some­one who’s watch­ing my traf­fic from know­ing what I’m say­ing. That’s one side. And then the flip side of that is authen­ti­ca­tion, prov­ing to the per­son that I am talk­ing to—intend to be talk­ing to, that I am who I say I am. And they’re real­ly com­ple­men­tary sides of the same thing. 

Malamud: Are there oth­er aspects to secu­ri­ty? I can see authen­ti­ca­tion being very impor­tant at the ser­vice lev­el. Someone’s tel­net­ing in or some­one is send­ing mail. I can see the con­fi­den­tial­i­ty being impor­tant at the data link or trans­port lev­el. Are we also wor­ried about secu­ri­ty at the IP lev­el, for exam­ple, spoof­ing an IP address?

Karn: Yes, yes. In fact that’s what the IP Security Working Group is work­ing on right now. They’re focus­ing on a net­work lay­er secu­ri­ty pro­to­col that by def­i­n­i­tion would encrypt indi­vid­ual IP datagrams—encrypt and/or authen­ti­cate them, depend­ing on how you have it con­fig­ured. This would allow me to for exam­ple set up a secu­ri­ty gate­way at a typ­i­cal com­pa­ny which has a fire­wall between their inter­nal net­work and the out­side world and allow their own peo­ple or any autho­rized user to punc­ture through that fire­wall and gain trans­par­ent con­nec­tiv­i­ty to the inside sub­net with­out hav­ing to recon­fig­ure the fire­wall each time. And do it in such a way that oth­er peo­ple would not be able to exploit that.

Malamud: So every sin­gle pack­et is authenticated?

Karn: Every sin­gle pack­et can be authenticated.

Malamud: Isn’t that rather inefficient?

Karn: Not nec­es­sar­i­ly. Again, there are hybrid cryp­to sys­tems that can be used for authen­ti­ca­tion just as they’re used for con­fi­den­tial­i­ty. The simple-minded thing would be to sim­ply sign using RSA every pack­et that I send, but that would be infea­si­ble. That’s sim­ply too expen­sive in CPU type. So again what you would do is you would exchange…you would set up a shared secret between the two enti­ties that wish to authen­ti­cate each oth­er. And then they would use fast single-key schemes to actu­al­ly sign each packet. 

For exam­ple, let’s say I use Diffie-Hellman to estab­lish a key shared by the two par­ties that wish to com­mu­ni­cate. I would then use RSA to sign that key to make sure that the keys is authen­tic, has not been mod­i­fied in flight. And then I could use MD5, the Message Digest algo­rithm, to actu­al­ly sign indi­vid­ual pack­ets, and that goes very very fast. MD5 can run at megabytes per sec­ond on most computers.

Malamud: Does this require us to change the IP imple­men­ta­tion on every host and every router to accom­mo­date this?

Karn: No. Another advan­tage of the IP-level secu­ri­ty approach is that it is very mod­u­lar. It can be imple­ment­ed in an end sys­tem. An end sys­tem could insert an IP secu­ri­ty head­er between IP and TCP, or UDP, what­ev­er trans­fer pro­to­col it’s using, but it does­n’t have to. It could also be done by an inter­me­di­ate sys­tem act­ing on behalf of all the sys­tems behind it. That inter­me­di­ate sys­tem could encap­su­late the pack­ets sent by the end sys­tems that are not security-aware. It could encap­su­late them using one of the IP in IP encap­su­la­tion pro­to­cols and then pro­tect that entire pack­et using the IP Security pro­to­col, either by authen­ti­cat­ing or encrypt­ing it or both.

Malamud: So no mat­ter what hap­pens on the IP Next Generation con­tro­ver­sy on whether it’s TUBA, or SIP, or one of those, is the work of the IP Security group going to be able to fit inside the next generation?

Karn: It cer­tain­ly should. It’s just anoth­er pro­to­col that can be insert­ed between the net­work lay­er and trans­port lay­er. And there’s no rea­son at all why it should not be direct­ly appli­ca­tion to the next gen­er­a­tion of IP pro­to­cols. We may have to be care­ful about field widths for address­es; oth­er than that there’s no rea­son why it should­n’t trans­late direct­ly to the next generation. 

Malamud: So we’ve looked at that secu­ri­ty at a vari­ety of lev­els, down at the data link, at the IP lev­el. Are there oth­er places that secu­ri­ty needs to be built into the Internet protocols?

Karn: Well, so far the lev­el that’s got­ten the most atten­tion for secu­ri­ty has been the appli­ca­tion lay­er. We have SNMP secu­ri­ty, we have FTP secu­ri­ty, we have tel­net secu­ri­ty and so forth. And it was from watch­ing all that activ­i­ty that I decid­ed that maybe it was time to look at doing secu­ri­ty at the IP lay­er. Because we’re real­ly try­ing to do the same thing all over again each of the appli­ca­tions. And since we only have one IP, at least at the moment we only have one IP, we could think of using a sin­gle secu­ri­ty ser­vice to pro­tect all appli­ca­tions rather than hav­ing to rein­vent a sep­a­rate secu­ri­ty ser­vice for every new appli­ca­tion we come up with. 

Now there are still places where application-level secu­ri­ty is the right thing. For exam­ple in elec­tron­ic mail. Electronic mail pass­es over links oth­er than SMTP TCP/IP paths. That’s why you still need things like Privacy-Enhanced Mail and PGP to pro­vide true end-to-end pro­tec­tion of elec­tron­ic mail. But for those ser­vices that’re run­ning direct­ly on top of the Internet pro­to­cols, I think the Internet secu­ri­ty approach is a very work­able way to go. 

Malamud: They say secu­ri­ty is only as good as the weak­est link. And it seems to me that ulti­mate­ly we end up with the user typ­ing in a pass­word. Um…

Karn: That’s one way of doing it.

Malamud: Are there oth­er ways to pro­tect this very very edge of the Internet? Because obvi­ous­ly what we’re authen­ti­cat­ing here is not the user but the soft­ware pro­gram on his computer.

Karn: That’s right. That’s right. Traditionally we’ve use pass­words. That’s only one of sev­er­al things that could be done. You can base authen­ti­cat­ing, which is what you’re real­ly doing with a pass­word, on some­thing you know or some­thing you have, or com­bi­na­tions of the two. Something you know, obvi­ous­ly a pass­word falls in that cat­e­go­ry. Something you have might be a smart card, for exam­ple. And you might think of com­bi­na­tions of the two where the smart card does­n’t work until you type in some­thing you know like a PIN. So there are com­bi­na­tions of the two. There are oth­er schemes which are a lit­tle more exot­ic that have to do with what you are, oth­er words reti­nal scans and so forth, but I don’t think they’re real­ly ready for prime time.

Malamud: How far away are we from see­ing things like smart cards being used to get us into systems?

Karn: Uh, inter­est­ing ques­tion. Smart cards seem to’ve become much more pop­u­lar in places like Europe than they have in the United States. It’s sim­ply not tak­en off in the United States. And there’s actu­al­ly a rather inter­est­ing rea­son for that. It has to do with the cost of telecom­mu­ni­ca­tions. One of the biggest advan­tages of pub­lic key cryp­to sys­tems like RSA is that much of the authen­ti­ca­tion can be done offline. You can prove to me that you are who you say you are with­out me hav­ing to go to some cen­tral serv­er to find out because you could hand me signed cer­tifi­cates that I can eas­i­ly ver­i­fy with infor­ma­tion I already have.

In the United States, how­ev­er, for appli­ca­tions such as cred­it card ver­i­fi­ca­tion, tele­phone calls are so cheap in the United States com­pared to Europe that they fig­ure it’s eas­i­er just to go ahead and give the guy a cheap plas­tic card and have him call into a data­base every time he makes a pur­chase to ver­i­fy him. In Europe, how­ev­er, com­mu­ni­ca­tions is much more expen­sive. So RSA-type smart cards, or smart cards in gen­er­al, become much more pop­u­lar as a way of cut­ting down telecom­mu­ni­ca­tions costs.

Malamud: Should we be rais­ing tele­phone rates in the US to pro­mote security?

Karn: No, I don’t think so. Of course anoth­er fac­tor is the fact that RSA is patent­ed only with­in the United States. So the Europeans are free to use it with­out pay­ing the roy­al­ties. That may be a sec­ondary factor.

Malamud: This sounds like an area that maybe we could use some gov­ern­ment involvement.

Karn: Well… I could argue the gov­ern­men­t’s already too involved in secu­ri­ty and I would wish they would just get out of our way and let us apply the tech­niques that we already know. 

Malamud: Well thank you very much. We’ve been talk­ing to Phil Karn [music starts] and this has been Geek of the Week.

Karn: Great. [indis­tinct due to music]


Malamud: This is Internet Talk Radio, flame of the Internet. You’ve been lis­ten­ing to Geek of the Week. You may copy this pro­gram to any medi­um and change the encod­ing, but may not alter the data or sell the con­tents. To pur­chase an audio cas­sette of this pro­gram, send mail to radio@​ora.​com.

Support for Geek of the Week comes from Sun Microsystems. Sun, The Network is the Computer. Support for Geek of the Week also comes from O’Reilly & Associates, pub­lish­ers of the Global Network Navigator, your online hyper­text mag­a­zine. For more infor­ma­tion, send email to info@​gnn.​com. Network con­nec­tiv­i­ty for the Internet Multicasting Service is pro­vid­ed by MFS DataNet and by UUNET Technologies.

Executive pro­duc­er for Geek of the Week is Martin Lucas. Production Manager is James Roland. Rick Dunbar and Curtis Generous are the sysad­mins. This is Carl Malamud for the Internet Multicasting Service, town crier to the glob­al village.