Getting your name on a patent app is pretty damn easy... at the Large Silly Valley company that I worked for, it was a matter of just putting somebody's name on the app and having them sign the various forms.
Given that Jobs is CEO, there's probably a "coolness" factor for anybody at Apple to have him on as a co-inventor. It certainly doesn't say anything about how involved (or not) he was in coming up with the idea. It's not like there's a quiz at the patent office to see if you are worthy of being a co-inventor, after all.
what a great idea! try http://www.dkim.org/ for more information on the best bet for getting a deployable protocol out there for authenticating email. It's currently going through IETF standarization, but the -allman-01 draft is stable and has multiple interoperable implementations including a sourceforge sendmail milter.
Remember that meteorite thingy that NASA announced several years back which supposedly showed signs of life? If nothing else, it shows that it's not impossible to blast parts of one planet onto another nearby planet. So if we find life on Mars, how will we know that it wasn't Earth cross contamination from, oh say, a bad-day-for-T-Rex asteroid?
Um no, this is completely misinformed. IPv6 is not being used, and IPv4 handles QoS just fine. The IPv6 flowlabel is just now being standardized, and is orthogonal to the DSCP which is in both IPv4 and IPv6 (something of a substitute for the normal 5-tuple flow classifier).
IPv6 will be good for VoIP, but to say that it is being used is just plain wrong. If only.
> Dude, using IP dosn't mean they are transfering > call trafic over the general internet. I really > doubt they are going to give each phone line a > real IP address rather then a 'local' one.
I think you're conflating two things here: address availability and quality of service. VoIP is very good candidate for where you'd really, really like to have globally routable addresses because you really, really want the RTP traffic (if not the signaling) to be end to end -- and hence free of snoopers or man in the middle attacks. Hence what you really want is IPv6. This has been something that I've been recommending for going on 5 years now as an inevitable need for VoIP. The 3G guys also get this and are requiring IPv6 in their handsets. This argument (along with the mobile IPv6 route optimization), in fact, turned the tide at one routing vendor with whom most people are acquainted.
The QoS angle, however, isn't really a function of "public" vs. "private" Internets, per se. It's a function of treatment and the SLA's which can be cobbled together. Many carriers who are (or were until the service provider's China Syndrome) planning on rolling out VoIP *do* plan on putting the traffic over their normal Internet backbone, mostly intending to use Diffserv marking (typically DSCP 5 for EF PHB's for RTP traffic) in their core. Some are planning to use first hop admission control in the form of RSVP (cable), but the whole area of cross-provider QoS treatment is still something of an unknown. Their expectation is that they can get SLA's with other providers when needed, or always just carry it on their own network. This is mainly due to their current view of their business model which though running over the public internet, views the VoIP service as a vertical service modeled on the old Telephant business model (ie, they do everything). That is, they aren't looking that far out. For the time being, if that business model results in medium to large sized islands of VoIP service with QoS, that would be a generally good thing since it will ultimately give reason to start interconnecting those islands, and hence the QoS assurances.
And this is hardly a dream. The technology has been maturing at a very rapid rate; it's been the provider meltdown that's really been the largest issue. This wasn't true about 3 years ago. If they went back into invest mode again, they'd find that what was bleeding edge and only for those of stout heart is now stable and well tested.
There is no "backdoor." The mediation device has control of the TAP MIB, that's all. This is just a normal SNMPv3 USM user with normal SNMPv3 keys. If those keys get hacked, you have a hell of a lot more problems than revealing the subject of taps.
The undetectability requirement is that the subject of a tap not be able to know they are being tapped. Also: there is a requirement that only authorized personnel be capable of seeing tap information, and not just any random NOC monkey. All of this is completely analogous to the implementation of CALEA requirements for the Bellheaded set.
But this is/. where ill-informed kneejerking is an artform.
Re:Wouldn't you want your VoIP encrypted anyway?
on
Snooping on VOIP
·
· Score: 1
Encryption for RTP is past IESG last call in the form of SRTP. Beyond that there's the problem of how to rendezvous. For SIP and MGCP, there's currently no widespread way of signaling the SRTP parameters in SDP. There's both MIKEY and draft-baugher-mmusic-sdpmediasec-00.txt which extend the semantics, MIKEY being rather heavy duty and draft-baugher being more direct and to the point. MIKEY allows the SDP announcement to be encrypted itself, whereas draft-baugher relies on either transitive trust through intermediaries, or something like SMIME for the body part including the SDP.
In both cases, there's the general problem of public key distribution. That is, if I go through intermediaries like SIP proxies, I may well not have any clue as to what you're public key is (think of forking proxies). This is really the large unsolved problem -- and is the reason you don't get much SMIME or PGP mail either.
So, this isn't going to be especially secure from the Feds through any time soon. For point to point communications where you already know the phone's FQDN, it can be made to be quite secure with SRTP and draft-baugher, but the rest remains problematic.
Cisco's UBR has been able to deal with this problem quite effectively for a very long time. With DOCSIS, all of the traffic is transmitted on virtual channels (SIDS) which can be encrypted (BPI+). Adjacent users on the same cable do not see each other's unencrypted traffic. This provides the ability of turn on proxy ARP at the cable router. For cable, it's even better since all users are required to get their IP addresses through DHCP and the router can download its the DHCP lease database when it reboots closing even _that_ hole.
The only thing I can think is that Adephia is just being boneheaded here (or has bought brand-X equipment for which they got what they paid for).
> Sure, they'll throw in encryption and such, but > that will be breakable as well. What Sony will > see as a huge investment, a lot of hackers / > crackers will see as an exercise in server > emulation.
Are you completely unaware of public key cryptography? How, exactly, do you propose that those hackers are going to obtain a copy of Sony's private signing key? To assert that is to assert that the public key cryptography model is fundamentally broken.
This is a classic opportunity for deploying a PKI, and it's not even all that hard of a PKI to set up since it's just the devices which would need to verify a few servers which chain back to a small number of trusted roots.
Just how is one supposed to "forge" a digital watermark? I would assume that a player enforcing some sort of DRM would require a form of a global PKI with, assumedly, M$, Disney, etc, etc in control of the root. In order for me to forge, I'd need access to the private key somewhere in that PKI chain for my signed content. That is, the player would have to be able to authenticate and authorize the content, and that in turn requires access to trusted private keys to vouch for your identity.
So I'm probably naive, but this sure looks mostly like a no-op to me.
"It's kind of weird, seeing an internet draft using protocol-like terminology to describe how people and companies (rather than computers) are supposed to interact with one another. I hope this isn't supposed to be an RFC, or else that this kind of thing is normal for the IETF (I haven't read that many IETF docs). I've never seen a thing like this and it seems to turn the IETF into an even more political body than it already is. I thought the IETF was supposed to make recommendations about bits and packets, not people and companies."
Uh, this is a perfectly normal for a Best Common Practices (BCP). I assume that's what's intended here, or perhaps just fodder for the plenary or something.
Yeah, it all sounds very, very scary... Big old Telesaur Rex
gnatching his teeth, and growling at the top of this lungs...
except for the fact that 802.11 is still here and still not
monopolized by the telesaurs. Oh, by the way,
hotspotting with 802.11 to not chew up their precious
cellular spectrum is seen as very attractive too by the
telesaurs, hence you'll eventually see dual mode wireless
widgets even if nobody got the bright idea that hooking
up to a cheap 802.11 network -- maybe for free in various
places -- would be a cool thing to do with your cell
phones and wireless widgets.
But the real thing that makes the garden walls most
suspect as a business model is all it takes is for one the
telesaurs to blink and plug it into the Internet. AOL
thought they had the ultimate walled garden too,
but in the end they finally blinked because there was far
too much content elsewhere and people would have left.
This isn't exactly the same, but the prospect of lots of
cheap 802.11 coverage (ie, retail, business, airports...)
which will clearly just drop directly off onto the Internet
will make their garden walls a lot more like a tar pit than
a gold mine.
The notion that IPsec has lots of overhead is largerly bogus.
As a proof, I wrote simple wrappers around sendto/recvfrom
for ESP transport mode with hmac-md5 and no encryption.
It interoperates with Freeswan with manual keying just fine.
The total code footprint was about 6k, 5k of which was the md5 hmac. Encryption could easily be added, and for a
point to point application like AP/host you don't *really* need tunnel mode, though if they were smart they use IPv6 and link local addressing with autoconfiguration -- you're going to need router advertisements for mobility eventually, after all.
Of course, aside from the completely bone headed reuse of RC4 keystream, the actual Hard Problem is key distribution. Why the 802.11 guys want to revinvent this is a complete mystery to me. IPsec has IKE -- which is about to get a face lift in the form of either JFK, IKEv2 or most likley a combination of these proposals. IPsec also has KINK (Kerberized IPsec) which is about to go to last call. Eventually, I expect that AAA (DIAMETER) based IPsec keying will be formalized since they're already toeing that line in many areas.
Yet, the 802.11 folks still want to roll their own. Ick. How this will all play out with fast mobility (ie so you can run voip instead of circuit switched voice on CDMA/802.11 dual mode phones that will eventually appear) will be very interesting. My guess is that it won't until somebody takes an integrated look at
security, quality of service, admission control, etc. I have some hope that the IETF protocols will eventually get this right, but the best I can hope for the L2 folks is that we can turn all of this krufty L2 wheel-reinvention off.
Multihoming will cause BGP route advertisements to go
exponential, and it's an exponential growth that Moore's
law cannot keep up with. This is very worrisome. The
reason
is because multihoming breaks heirarchical
addressing
assumptions, especially the assumptions that
the last round
of CIDR bandaids made. I don't know why
people keep
bringing up IPv6. Its design wasn't intended
to deal with
route table growth, and while some people
think it may
be somewhat helpful since it will start with
CIDR from the
get-go, it still expects a heirarchical
provider address
space.
This is very old news though,
and the source of lots of
flamage on the v6-haters list,
including a lot of people
who think the IESG completely
fucked up by solving
the wrong problem (address depletion vs. route explosion).
Actually, DOCSIS 1.1 isn't really needed. I believe that the
DOCSIS 1.0 config file -- which the CMTS partially reads
-- has the ability to specify a SLA to police that modem's
best effor SID to. Thus, it is a matter of implementation
on the CMTS to be able to shape traffic. I'm pretty sure
that the Cisco UBR is capable of enforcing these SLA's,
so as usual this is a smokescreen by the MSO's.
FYI, DOCSIS 1.1 is mainly intended to get better than best
effort traffic, which is aimed pretty squarely at VoIP
applications with unsolicited grant service. You ain't
gonna get that unless you pay for it, and the mechanism's
are already defined in the Packetcable DQoS spec.
While it's certainly reasonable to want authentication
even if you're not going to be charging BigBux for it,
taking a web-centric approach to using a net is not
really going to cut it going forward. Using the web as
an _enrollement_ tool is probably fine, but if you want
to be running VoIP phones which need real time handoff
capabilities, let's see... "Hold on while I sign up for service
on this new AP...". I don't think so.
Fast roaming is going ot require a better authentication
subsystem which is inherently single signon and will
almost certainly requires cross realm agreements so that
you can move from cellular to 802.11 to whatever
seamlessly. My personal fave candidate is to use kerberos
mechanisms since it allows amortization of expensive
public operations, but other heroism may be needed in
the form of the icky prospect of transfering AAA, SA, and
QoS authorization context across access routers, etc.
> I worked on the Sprint ION project for over a year
> as a software engineer, and I got to know the
> system pretty well.
Me too.
> Sprint decided to implement all of these services
> over an ATM network. ATM AAL2 rt-vbr (realtime
> variable bit rate)
And this is where the train departed the track. The
announcement the other day was just the kinetic
energy of the derailment catching up from the rear of
the train. Had they gone with VoIP instead of
whinging on endlessly about bandwidth in the core,
the project could have completed long ago. Instead
they bought into AAL2 snake oil and got exactly what
was predictable two years ago.
> and only ION had the capability to provide such high
> quality of service features directly into the home
> (you need ATM for this level of QoS)
BS. This is ATM bigotry. An IP network with diffserv
and/or intserv could easily achieve this, and is
shipping today. Also: you can run AAL5 over CBR or
VBR SVC just as easily as AAL2, and you can use
Q.2931 to signal for vc setup just like any other
over-complicated L2.
> I worked on the Sprint ION project for over a year
> as a software engineer, and I got to know the
> system pretty well.
Me too.
> Sprint decided to implement all of these services
> over an ATM network. ATM AAL2 rt-vbr (realtime
> variable bit rate)
And this is where the train departed the track. The
announcement the other day was just the kinetic
energy of the derailment catching up from the rear of
the train. Had they gone with VoIP instead of
whinging on endlessly about bandwidth in the core,
the project could have completed long ago. Instead
they bought into AAL2 snake oil and got exactly what
was predictable two years ago.
> and only ION had the capability to provide such high
> quality of service features directly into the home
> (you need ATM for this level of QoS)
BS. This is ATM bigotry. An IP network with diffserv
and/or intserv could easily achieve this, and is
shipping today. Also: you can run AAL5 over CBR or
VBR SVC just as easily as AAL2, and you can use
Q.2931 to signal for vc setup just like any other
over-complicated L2.
If your router is so saturated that it's dropping BGP packets, this means that it's also dropping other packets. This is considered bad. Under normal circumstances, 'flapping' your route for a short period (the document indicates that BGP has a 30 second minumum)
will cause some of those packets to take the 'back' route, and will (hopefully) cause enough of a strain relief on the overloaded router for it to catch up to the (normally transient) overload.
This isn't quite true. On a distributed architecture, or when you have hardware assist, etc, you can slag the main processor by sending enough cruft up on the slow path, but the forwarding engines would still keep humming along.
Ah, you seem to be saying that TCAM thrashing is
what is at the root of this. I'm not so sure about that.
For one, the GSR doesn't use a TCAM architecture nor any of of the processor based boxen (which is most of the edge boxen up until recently) . The FIB lookups are all done using the standard MTRIE algorithm. Secondly, I'm not sure why that would affect BGP _specifically_; ie, you'd expect that that would cause general trouble rather than just routing stability trouble.
My bet is that this more akin to a flooding attack and that BGP is just one of the casualties. If that were the case, you'd expect that marking the BGP traffic and doing differential diffserv treatment for it would help restore stability (like, say, CBWFQ, etc.).
Something that often gets lost in furor over one of these outbreaks is what the core of the problem is. IP was designed around the end to end principle; dumb interior nodes (routers) and smart end nodes (hosts). This architecture replaced the notion of store and forward networks with intelligent network layers (application layer gateways). Firewalls, NAT's, and stateful inspection boxes (middle boxes) are nothing more than a return to the bad old days of ALG's and their direct implication: strangulation of new services because network-wide flag days are impossible.
Anybody who doesn't understand this ought to take some time to read Elliot Lear's _Foglamps_ piece, as well as listen to some of Steve Deerings rants on network transparency (as presented at the last IETF plenery). To make a long story short, IP is a *very* poorly thought out architecture for an intelligent network, and trying to graft it back onto the current Internet is very, very ugly. Routers fundamentally know about forwarding packets and maybe some stuff about packet classification/scheduling. They don't know squat about the attack de jour, and anybody who tries to tell you otherwise is trying to sell you crack.
So what does that have to do with CmdrTaco's "kill them all, let the ISP sort them out" call? The problem is that disabling network functionality throws the new Internet services baby out with the bath water. How do you plan to run Voip services when both users are behind NAT's? How do not kill new services such as, oh say, napster, IM, etc, etc when the ISP's first response to a security meltdown is to shut off everything except "known applications"? Why would an ISP in their right mind ever lift those restrictions since it's obvious that it is in their best interest (= keep their NOC monkies from endless late nights) to kill first, ask questions later?
The _real_ problem here is the stupid idea that the great unwashed masses are capable of being their own sysadmins. This is silly on its face, but that is the state of the emperor's clothes today. What we really need is for service providers to step up to the job that is sorely lacking right now: a system manager service for people who don't understand or can't be bothered to want to do it for themselves.
Sounds crazy? Well consider the alternatives: strangulation of the net from fascist network admins whose tools are necessarily hamfisted, or death by thousands of script kiddies providing a 21st century tragedy of the commons.
Unfortunately, key distribution is one of the Really Hard Problems. SMTP (and other proxy routable protocols like SIP) are even worse because there is a hopwise problem (between your mta and the relay) and an end to end problem. While the hopwise problem is readily solveable using things like IPsec and TLS, the end to end problem is much more difficult. The reason is that unless you have some direct knowledge of the sender (their [public] key, say), you have to rely on third parties who vouch for you. This works adequately when the scaling can be confined within a limited set of trust relationships (limited PKI's, limited x-realm Kerberos, etc), but breaks down when you start positing the mythical global PKI.
Mail, web browsing and other many-to-many kinds of problems (and most likely telephony too, depending on how it is deployed) require mutually agreed upon roots of trust, and those are hard (maybe impossible) to come by. Worse: even if they did exist, it is not entirely clear that that would be a Good Thing. As Jeff Schiller pointed out at IETF50 (in reference to the global PKI implications of mobile IPv6's binding updates), Global xxx's breed reptiles, and having, oh say, ICAAN in charge of global PKI's for IP prefixes, rfc822 names, DNS, etc, etc is not an especially comforting thought.
Setting our sites smaller at this point in time is probably the best that can be hoped for. That means doing the hopwise crypto, and using strong authentication e2e within the realms you either control, or can work out agreements with. PKCross with Kerberos is another angle that might allow for larger and larger trust aggregates (since you get a centralized online policy engines in the form of KDC's), but that may be a pipe dream too.
Slashdot Mirror
Getting your name on a patent app is pretty damn easy... at the Large Silly Valley company
that I worked for, it was a matter of just putting somebody's name on the app and having them
sign the various forms.
Given that Jobs is CEO, there's probably a "coolness" factor for anybody at Apple to have him
on as a co-inventor. It certainly doesn't say anything about how involved (or not) he was in
coming up with the idea. It's not like there's a quiz at the patent office to see if you are
worthy of being a co-inventor, after all.
what a great idea! try http://www.dkim.org/ for more information
on the best bet for getting a deployable protocol out there for
authenticating email. It's currently going through IETF standarization,
but the -allman-01 draft is stable and has multiple interoperable implementations
including a sourceforge sendmail milter.
Remember that meteorite thingy that NASA announced several years back which supposedly showed signs of life? If nothing else, it shows that it's not impossible to blast parts of one planet onto another nearby planet. So if we find life on Mars, how will we know that it wasn't Earth cross contamination from, oh say, a bad-day-for-T-Rex asteroid?
Um no, this is completely misinformed. IPv6 is not being used, and IPv4 handles QoS just fine. The IPv6 flowlabel is just now being standardized, and is orthogonal to the DSCP which is in both IPv4 and IPv6 (something of a substitute for the normal 5-tuple flow classifier).
IPv6 will be good for VoIP, but to say that it is being used is just plain wrong. If only.
Uh, diffserv marking and fair queuing are your friends. Really. Become acquainted with them.
> Dude, using IP dosn't mean they are transfering
> call trafic over the general internet. I really
> doubt they are going to give each phone line a
> real IP address rather then a 'local' one.
I think you're conflating two things here: address availability and quality of service. VoIP is very good candidate for where you'd really, really like to have globally routable addresses because you really, really want the RTP traffic (if not the signaling) to be end to end -- and hence free of snoopers or man in the middle attacks. Hence what you really want is IPv6. This has been something that I've been recommending for going on 5 years now as an inevitable need for VoIP. The 3G guys also get this and are requiring IPv6 in their handsets. This argument (along with the mobile IPv6 route optimization), in fact, turned the tide at one routing vendor with whom most people are acquainted.
The QoS angle, however, isn't really a function of "public" vs. "private" Internets, per se. It's a function of treatment and the SLA's which can be cobbled together. Many carriers who are (or were until the service provider's China Syndrome) planning on rolling out VoIP *do* plan on putting the traffic over their normal Internet backbone, mostly intending to use Diffserv marking (typically DSCP 5 for EF PHB's for RTP traffic) in their core. Some are planning to use first hop admission control in the form of RSVP (cable), but the whole area of cross-provider QoS treatment is still something of an unknown. Their expectation is that they can get SLA's with other providers when needed, or always just carry it on their own network. This is mainly due to their current view of their business model which though running over the public internet, views the VoIP service as a vertical service modeled on the old Telephant business model (ie, they do everything). That is, they aren't looking that far out. For the time being, if that business model results in medium to large sized islands of VoIP service with QoS, that would be a generally good thing since it will ultimately give reason to start interconnecting those islands, and hence the QoS assurances.
And this is hardly a dream. The technology has been maturing at a very rapid rate; it's been the provider meltdown that's really been the largest issue. This wasn't true about 3 years ago. If they went back into invest mode again, they'd find that what was bleeding edge and only for those of stout heart is now stable and well tested.
There is no "backdoor." The mediation device has control of the TAP MIB, that's all. This is just a normal SNMPv3 USM user with normal SNMPv3 keys. If those keys get hacked, you have a hell of a lot more problems than revealing the subject of taps.
/. where ill-informed kneejerking is an artform.
The undetectability requirement is that the subject of a tap not be able to know they are being tapped. Also: there is a requirement that only authorized personnel be capable of seeing tap information, and not just any random NOC monkey. All of this is completely analogous to the implementation of CALEA requirements for the Bellheaded set.
But this is
Encryption for RTP is past IESG last call in the form of SRTP. Beyond that there's the problem of how to rendezvous. For SIP and MGCP, there's currently no widespread way of signaling the SRTP parameters in SDP. There's both MIKEY and draft-baugher-mmusic-sdpmediasec-00.txt which extend the semantics, MIKEY being rather heavy duty and draft-baugher being more direct and to the point. MIKEY allows the SDP announcement to be encrypted itself, whereas draft-baugher relies on either transitive trust through intermediaries, or something like SMIME for the body part including the SDP.
In both cases, there's the general problem of public key distribution. That is, if I go through intermediaries like SIP proxies, I may well not have any clue as to what you're public key is (think of forking proxies). This is really the large unsolved problem -- and is the reason you don't get much SMIME or PGP mail either.
So, this isn't going to be especially secure from the Feds through any time soon. For point to point communications where you already know the phone's FQDN, it can be made to be quite secure with SRTP and draft-baugher, but the rest remains problematic.
Cisco's UBR has been able to deal with this problem quite effectively for a very long time. With DOCSIS, all of the traffic is transmitted on virtual channels (SIDS) which can be encrypted (BPI+). Adjacent users on the same cable do not see each other's unencrypted traffic. This provides the ability of turn on proxy ARP at the cable router. For cable, it's even better since all users are required to get their IP addresses through DHCP and the router can download its the DHCP lease database when it reboots closing even _that_ hole.
The only thing I can think is that Adephia is just being boneheaded here (or has bought brand-X equipment for which they got what they paid for).
> Sure, they'll throw in encryption and such, but
> that will be breakable as well. What Sony will
> see as a huge investment, a lot of hackers /
> crackers will see as an exercise in server
> emulation.
Are you completely unaware of public key
cryptography? How, exactly, do you propose that
those hackers are going to obtain a copy of Sony's
private signing key? To assert that is to assert
that the public key cryptography model
is fundamentally broken.
This is a classic opportunity for deploying a PKI,
and it's not even all that hard of a PKI to set up
since it's just the devices which would need to
verify a few servers which chain back to a small
number of trusted roots.
Just how is one supposed to "forge" a digital
watermark? I would assume that a player enforcing
some sort of DRM would require a form of a global
PKI with, assumedly, M$, Disney, etc, etc in
control of the root. In order for me to forge, I'd
need access to the private key somewhere in that
PKI chain for my signed content. That is, the
player would have to be able to authenticate and
authorize the content, and that in turn requires
access to trusted private keys to vouch for your
identity.
So I'm probably naive, but this sure looks
mostly like a no-op to me.
Yeah, and they can probably reuse the rest of the whacko Exodus ex-gay screed:
"You too can make your way out of the harmful
Open-Source Lifestyle."
"It's kind of weird, seeing an internet draft using protocol-like terminology to describe how people and companies (rather than computers) are supposed to interact with one another. I hope this isn't supposed to be an RFC, or else that this kind of thing is normal for the IETF (I haven't read that many IETF docs). I've never seen a thing like this and it seems to turn the IETF into an even more political body than it already is. I thought the IETF was supposed to make recommendations about bits and packets, not people and companies."
Uh, this is a perfectly normal for a Best Common
Practices (BCP). I assume that's what's intended here,
or perhaps just fodder for the plenary or something.
Yeah, it all sounds very, very scary... Big old Telesaur Rex
gnatching his teeth, and growling at the top of this lungs...
except for the fact that 802.11 is still here and still not
monopolized by the telesaurs. Oh, by the way,
hotspotting with 802.11 to not chew up their precious
cellular spectrum is seen as very attractive too by the
telesaurs, hence you'll eventually see dual mode wireless
widgets even if nobody got the bright idea that hooking
up to a cheap 802.11 network -- maybe for free in various
places -- would be a cool thing to do with your cell
phones and wireless widgets.
But the real thing that makes the garden walls most
suspect as a business model is all it takes is for one the
telesaurs to blink and plug it into the Internet. AOL
thought they had the ultimate walled garden too,
but in the end they finally blinked because there was far
too much content elsewhere and people would have left.
This isn't exactly the same, but the prospect of lots of
cheap 802.11 coverage (ie, retail, business, airports...)
which will clearly just drop directly off onto the Internet
will make their garden walls a lot more like a tar pit than
a gold mine.
-- Mike
Of course, aside from the completely bone headed reuse of RC4 keystream, the actual Hard Problem is key distribution. Why the 802.11 guys want to revinvent this is a complete mystery to me. IPsec has IKE -- which is about to get a face lift in the form of either JFK, IKEv2 or most likley a combination of these proposals. IPsec also has KINK (Kerberized IPsec) which is about to go to last call. Eventually, I expect that AAA (DIAMETER) based IPsec keying will be formalized since they're already toeing that line in many areas.
Yet, the 802.11 folks still want to roll their own. Ick. How this will all play out with fast mobility (ie so you can run voip instead of circuit switched voice on CDMA/802.11 dual mode phones that will eventually appear) will be very interesting. My guess is that it won't until somebody takes an integrated look at security, quality of service, admission control, etc. I have some hope that the IETF protocols will eventually get this right, but the best I can hope for the L2 folks is that we can turn all of this krufty L2 wheel-reinvention off.
Multihoming will cause BGP route advertisements to go
exponential, and it's an exponential growth that Moore's
law cannot keep up with. This is very worrisome. The
reason is because multihoming breaks heirarchical
addressing assumptions, especially the assumptions that
the last round of CIDR bandaids made. I don't know why
people keep bringing up IPv6. Its design wasn't intended
to deal with route table growth, and while some people
think it may be somewhat helpful since it will start with
CIDR from the get-go, it still expects a heirarchical
provider address space.
This is very old news though, and the source of lots of
flamage on the v6-haters list, including a lot of people
who think the IESG completely fucked up by solving
the wrong problem (address depletion vs. route explosion).
Actually, DOCSIS 1.1 isn't really needed. I believe that the
DOCSIS 1.0 config file -- which the CMTS partially reads
-- has the ability to specify a SLA to police that modem's
best effor SID to. Thus, it is a matter of implementation
on the CMTS to be able to shape traffic. I'm pretty sure
that the Cisco UBR is capable of enforcing these SLA's,
so as usual this is a smokescreen by the MSO's.
FYI, DOCSIS 1.1 is mainly intended to get better than best
effort traffic, which is aimed pretty squarely at VoIP
applications with unsolicited grant service. You ain't
gonna get that unless you pay for it, and the mechanism's
are already defined in the Packetcable DQoS spec.
While it's certainly reasonable to want authentication
even if you're not going to be charging BigBux for it,
taking a web-centric approach to using a net is not
really going to cut it going forward. Using the web as
an _enrollement_ tool is probably fine, but if you want
to be running VoIP phones which need real time handoff
capabilities, let's see... "Hold on while I sign up for service
on this new AP...". I don't think so.
Fast roaming is going ot require a better authentication
subsystem which is inherently single signon and will
almost certainly requires cross realm agreements so that
you can move from cellular to 802.11 to whatever
seamlessly. My personal fave candidate is to use kerberos
mechanisms since it allows amortization of expensive
public operations, but other heroism may be needed in
the form of the icky prospect of transfering AAA, SA, and
QoS authorization context across access routers, etc.
> I worked on the Sprint ION project for over a year
> as a software engineer, and I got to know the
> system pretty well.
Me too.
> Sprint decided to implement all of these services
> over an ATM network. ATM AAL2 rt-vbr (realtime
> variable bit rate)
And this is where the train departed the track. The
announcement the other day was just the kinetic
energy of the derailment catching up from the rear of
the train. Had they gone with VoIP instead of
whinging on endlessly about bandwidth in the core,
the project could have completed long ago. Instead
they bought into AAL2 snake oil and got exactly what
was predictable two years ago.
> and only ION had the capability to provide such high
> quality of service features directly into the home
> (you need ATM for this level of QoS)
BS. This is ATM bigotry. An IP network with diffserv
and/or intserv could easily achieve this, and is
shipping today. Also: you can run AAL5 over CBR or
VBR SVC just as easily as AAL2, and you can use
Q.2931 to signal for vc setup just like any other
over-complicated L2.
> I worked on the Sprint ION project for over a year > as a software engineer, and I got to know the > system pretty well. Me too. > Sprint decided to implement all of these services > over an ATM network. ATM AAL2 rt-vbr (realtime > variable bit rate) And this is where the train departed the track. The announcement the other day was just the kinetic energy of the derailment catching up from the rear of the train. Had they gone with VoIP instead of whinging on endlessly about bandwidth in the core, the project could have completed long ago. Instead they bought into AAL2 snake oil and got exactly what was predictable two years ago. > and only ION had the capability to provide such high > quality of service features directly into the home > (you need ATM for this level of QoS) BS. This is ATM bigotry. An IP network with diffserv and/or intserv could easily achieve this, and is shipping today. Also: you can run AAL5 over CBR or VBR SVC just as easily as AAL2, and you can use Q.2931 to signal for vc setup just like any other over-complicated L2.
If your router is so saturated that it's dropping BGP packets, this means that it's also dropping other packets. This is considered bad. Under normal circumstances, 'flapping' your route for a short period (the document indicates that BGP has a 30 second minumum)
will cause some of those packets to take the 'back' route, and will (hopefully) cause enough of a strain relief on the overloaded router for it to catch up to the (normally transient) overload.
This isn't quite true. On a distributed architecture, or when you have hardware assist, etc, you can slag the main processor by sending enough cruft up on the slow path, but the forwarding engines would still keep humming along.
Ah, you seem to be saying that TCAM thrashing is
what is at the root of this. I'm not so sure about that.
For one, the GSR doesn't use a TCAM architecture nor any of of the processor based boxen (which is most of the edge boxen up until recently) . The FIB lookups are all done using the standard MTRIE algorithm. Secondly, I'm not sure why that would affect BGP _specifically_; ie, you'd expect that that would cause general trouble rather than just routing stability trouble.
My bet is that this more akin to a flooding attack and that BGP is just one of the casualties. If that were the case, you'd expect that marking the BGP traffic and doing differential diffserv treatment for it would help restore stability (like, say, CBWFQ, etc.).
Do a google search on second system syndrome.
I work at a large silly valley employer who just
found out yet again that this is just as real an
effect today as it was 25 years ago.
Something that often gets lost in furor over one of these outbreaks is what the core of the problem is. IP was designed around the end to end principle; dumb interior nodes (routers) and smart end nodes (hosts). This architecture replaced the notion of store and forward networks with intelligent network layers (application layer gateways). Firewalls, NAT's, and stateful inspection boxes (middle boxes) are nothing more than a return to the bad old days of ALG's and their direct implication: strangulation of new services because network-wide flag days are impossible.
Anybody who doesn't understand this ought to take some time to read Elliot Lear's _Foglamps_ piece, as well as listen to some of Steve Deerings rants on network transparency (as presented at the last IETF plenery). To make a long story short, IP is a *very* poorly thought out architecture for an intelligent network, and trying to graft it back onto the current Internet is very, very ugly. Routers fundamentally know about forwarding packets and maybe some stuff about packet classification/scheduling. They don't know squat about the attack de jour, and anybody who tries to tell you otherwise is trying to sell you crack.
So what does that have to do with CmdrTaco's "kill them all, let the ISP sort them out" call? The problem is that disabling network functionality throws the new Internet services baby out with the bath water. How do you plan to run Voip services when both users are behind NAT's? How do not kill new services such as, oh say, napster, IM, etc, etc when the ISP's first response to a security meltdown is to shut off everything except "known applications"? Why would an ISP in their right mind ever lift those restrictions since it's obvious that it is in their best interest (= keep their NOC monkies from endless late nights) to kill first, ask questions later?
The _real_ problem here is the stupid idea that the great unwashed masses are capable of being their own sysadmins. This is silly on its face, but that is the state of the emperor's clothes today. What we really need is for service providers to step up to the job that is sorely lacking right now: a system manager service for people who don't understand or can't be bothered to want to do it for themselves.
Sounds crazy? Well consider the alternatives: strangulation of the net from fascist network admins whose tools are necessarily hamfisted, or death by thousands of script kiddies providing a 21st century tragedy of the commons.
Unfortunately, key distribution is one of the Really Hard Problems. SMTP (and other proxy routable protocols like SIP) are even worse because there is a hopwise problem (between your mta and the relay) and an end to end problem. While the hopwise problem is readily solveable using things like IPsec and TLS, the end to end problem is much more difficult. The reason is that unless you have some direct knowledge of the sender (their [public] key, say), you have to rely on third parties who vouch for you. This works adequately when the scaling can be confined within a limited set of trust relationships (limited PKI's, limited x-realm Kerberos, etc), but breaks down when you start positing the mythical global PKI.
Mail, web browsing and other many-to-many kinds of problems (and most likely telephony too, depending on how it is deployed) require mutually agreed upon roots of trust, and those are hard (maybe impossible) to come by. Worse: even if they did exist, it is not entirely clear that that would be a Good Thing. As Jeff Schiller pointed out at IETF50 (in reference to the global PKI implications of mobile IPv6's binding updates), Global xxx's breed reptiles, and having, oh say, ICAAN in charge of global PKI's for IP prefixes, rfc822 names, DNS, etc, etc is not an especially comforting thought.
Setting our sites smaller at this point in time is probably the best that can be hoped for. That means doing the hopwise crypto, and using strong authentication e2e within the realms you either control, or can work out agreements with. PKCross with Kerberos is another angle that might allow for larger and larger trust aggregates (since you get a centralized online policy engines in the form of KDC's), but that may be a pipe dream too.
Mike