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.


Help Support Open Transcripts

If you found this useful or interesting, please consider supporting the project monthly at Patreon or once via Cash App, or even just sharing the link. Thanks.