Re: MBONE access?
Ole didn't say Realplayer supports Multicast. He is asking why we can't use Real stream (or something along that line) instead. FYI, I didnt get mbone since 1995 when I stop working for an ISP. I have managed to get any of my current ISPs to get it either. It is time we have to admit mbone is not going mainstream. ps: https://helixcommunity.org/ - Real player (or at least Helix, the Open Source version of it) is available on multiplatform. -James Seng Frank Solensky wrote: A nit, perhaps, but: On Wed, 2004-03-03 at 20:17 -0800, Ole Jacobsen wrote: ..Note that Real Player is available for multiple platforms for free, .. The Linux version, last I tried [8.0.3.412], didn't include support for multicast.
Re: MBONE access?
[EMAIL PROTECTED] (James Seng) writes: ... FYI, I didnt get mbone since 1995 when I stop working for an ISP. I have managed to get any of my current ISPs to get it either. It is time we have to admit mbone is not going mainstream. today shep reminded me that we (shepfarm and isc, with help from cisco, juniper, procket, verio, and a cast of others) are supporting some number of mbone-like tunnels designed to glue otherwise disconnected walled gardens together, with touchdowns on fix-west, paix-sfba, and equinix-sj. naturally there'll be pressure toward (and aid offered toward) going native, but other than that these tunnels are free of cost. We *Can* Fix This. ps: https://helixcommunity.org/ - Real player (or at least Helix, the Open Source version of it) is available on multiplatform. if that increases the market for realnetworks' proprietary server-side products, and if realnetworks is still doing absolutely no confirmation on e-mail addresses they send bulk e-mail to, then i'll probably continue to boycott that application suite, no matter how free the players are. -- Paul Vixie
Re: MBONE access?
On 4-mrt-04, at 6:14, Joel Jaeggli wrote: There's a reasonable cross-section of clients for most platforms the supports a set of mostly interoperable codecs and transports. It is possible to source with real/darwin streaming server/videolan a source that will be visbile to users of quicktime/real/vlc and some other clients via multicast or unicast transports. Right. And unless I'm mistaken, streaming servers will happily take either a unicast or a multicast feed and reflect this feed over one of several transports (including some that will bypass NAT). The transport is an issue. 500Kb/s isma mpeg-4 streams have a real cost if you want 200 of them... That's 100 Mbps. There are a lot of outfits that care about the IETF for which 100 Mbps is small change. (The latest episode of the Steve Jobs Show had 60,000 people watching at 300 kbps...) And 200 x 24 kbps audio only is just 5 Mbps, which would even be doable from the meeting site. A reasonable charge to cover the costs for online participation wouldn't be out of the question either, IMO. The thing I consider most unworkable frankly is low-bitrate video... I don't consider a 40 80 100Kb/s streams terribly usable regardless of the codec chosen, I want to be able to read the slides, I want to be able hear the speakers from someplace other than the bottom a barrel and I want to be able to discern who's standing at the mic. Our little multi6 experiment taught me that low quality video indeed isn't all that useful, and goood quality video isn't simple. However, workable quality audio is both simple and useful. So if good video can't be done, forget about it altogether and do audio only. If the speakers get in the habit of putting their slides online before a session and either they or the jabber scribe say which slide is up, that part is covered. Another option would be slow scan tv: rather than stream relatively low quality moving video, why not send out periodic high quality stills? The advantage here is that there is no set rate at which those have to load so there is no binary good/none quality problem as with streaming.
On supporting NAT, was: Re: MBONE access?
On 4-mrt-04, at 2:44, Hallam-Baker, Phillip wrote: In case you had not noticed there are now tens of millions of NAT devices in use. End users are not going to pay $10 per month for an extra IP address when they can connect unlimited numbers of devices to the net using a $40 NAT box. Sounds like a conspiracy... ISPs charging orders of magnitude more than cost for additional addresses forcing people to use NAT. The NAT war has been over for years, NAT won. The problem is that the IETF still has not come to terms with that fact. I don't think anyone has won here, there are just casualties all over the place: more work for the IETF and vendors, less functionality for the users. The Internet was designed to be a network of networks. The core architecture is NOT end-to-end, that is a political shiboleth that has been imposed later. Suppose for the sake of argument that the above is a valid position, and that we would actually want to make NAT work. What we need to do then is extend it such that it becomes possible to address hosts behind a NAT from the public internet. That should be perfectly doable, in essence we'd be redefining the protocol and port numbers to be part of the address. However, this means these must now also be put in the DNS and in most other places where IP addresses show up. So this adds up to a HUGE amount of new work. Guess what: we already did pretty much the same thing with IPv6. The logical conclusion here is that we can save a lot of time and effort by simply adding IPv6 to the mix, as it is just a hair shy of being ready for full deployment, while all this stuff to make NAT actually work is all over the place. In the case of H323 the problem is not just NAT, it is the derranged protocol which uses a block of 3000 odd TCP/IP ports to receive messages on. there is no way that this is consistent with good firewall management So now you are complaining because after you install a firewall, it turns out the thing does its job? The whole idea that decent security can be had by allowing packets with certain port numbers in them in and not others is fatally flawed, as it just makes for an arms race between firewall vendors that inspect deeper and deeper into packes and firewall bypass utilities that tunnel the real protocol through more and more layers of accepted protocols. What we need is corporate zone alarm like functionality, where firewalls get to see which applications (and users) are trying to communicate with the outside world, rather than guess based on the port number in the packet. This would allow some very nice features such as blocking vulnerable versions of applications but allowing patched versions of the same application.
Re: MBONE access?
On Wed, 3 Mar 2004, Ole Jacobsen wrote: Paul, This is simply silly. What you are saying is that for religious reasons you are unwilling to use FREE and widely used tools in order to help us develop our own. Next thing you'll be telling me PDF is a bad thing. If you want the IETF to be a place where more people can participate you need to ditch some of this religion. ... the fact that realmedia and windowsmedia aren't interoperable means that we (this community) failed to recognize and address a common need, and that the world (including this community) is suffering for it. compounding this failure by adopting proprietary technology for the primary work of this community -- which is interior and published communications -- would be a bad, bad (bad) thing. This is not silly, it is just smart in a longer timeframe than you're thinking in. Proprietary tools that utilize a proprietary/non-open data interface are a serious problem for a variety of very sound, non-religious reasons (as well as for a variety of political and economic reasons, which is what I think you're calling religious reasons). Free is irrelevant to the issue, unless free means open. 1) Proprietary data formats and long term archiving of any sort of data are fundamentally incompatible. Ask anybody who has lived through the last twenty or thirty years of computer evolution how many documents they've lost or had to go in and rescue (sometimes at great expense) as the tools they were built with have disappeared. Sometimes along with their vendors. Other times the vendors simply decided to release a new version that was sufficiently incompatible that it could no longer manage the old documents. I think all of us can remember multiple instances where this has happened to us -- I personally have lived through wordstar, pcwrite, wordperfect, word, and several income tax programs (which are the worst, as one HAS to be able to access the records up to seven years later, which is a real problem with operating systems and Moore's Law). There is also the uncertainty even now surrounding the encumbered mp3 format versus e.g. the unencumbered ogg format. Formats used to encode long-term public records need to be open and tools to manage those records need to be available from many sources. So putting up realmedia shows is short-run glitzy and nifty and all that (even though lots of people won't have the players and cannot play the media) but it is long run foolish IF the production is intended as any sort of serious historical or archival record. 2) Using a proprietary data format that can only be accessed by using a proprietary tool (even a free one) leaves one vulnerable to all sorts of shenanigans and hidden costs. For example, nothing prevents the vendor from waiting until you have a large amount of valuable data built up with their format that would be very expensive to convert and then deciding to charge you. It's their tool, they can charge you if and when they please. Worse, since their tool is generally a closed source, proprietary object, there are the usual problems with libraries and compatibility when trying to get the tool to run on the wide range of platforms it is advertised for. Free may just refer to the cost of getting the program, but it may well cost quite a bit of time to install and maintain it, and time is money. 3) The Internet has been built on open standards from the very beginning. This is absolutely the key to its success and tremendous degree of universality and functionality to this very day. Any vendor can build a mail tool, an ftp tool, a tool using TCP/IP as a transport layer. Any vendor can build a browser, an http daemon. The specifications for those tools are laid out in RFCs, and modifications to the open standards proceed in a serious and systematic way. The Internet has RESISTED being co-opted by monopolistic vendors who have sought to introduce their own proprietary and essential layer of middleware on hidden protocols, although they continue trying. The DMCA makes it quite possible that if they ever succeed it will be tremendously expensive and damaging to the entire structure. You can call this a religious argument if you like, but I think it is really a statement of both politics and economics, in this case the politics of freedom and the economics associated with having lots of choices. So I'm afraid that I agree with Paul 100% on this one (although I respectfully disagree with him on others;-). The IETF absolutely should avoid using proprietary tools to create documents that they might wish to archive, and should strongly encourage the development of open standards for and open document formats (one data format, many tools both free and non-free) for data transmission on the Internet to ensure that the Internet NOT be co-opted by any single vendor and that records that might be archived today can still be accessed ten or twenty years from now without
RE: On supporting NAT, was: Re: MBONE access?
Sounds like a conspiracy... ISPs charging orders of magnitude more than cost for additional addresses forcing people to use NAT. Its called a monopoly. There are good reasons why ISPs are encouraging their customers to use NAT, they provide a weak firewall capability and that in turn significantly reduces exposure to being hacked which in turn reduces the cost of chasing zombie machines. The next generation of cable modems my ISP will be installing will have a NAT box built in. The NAT war has been over for years, NAT won. The problem is that the IETF still has not come to terms with that fact. I don't think anyone has won here, there are just casualties all over the place: more work for the IETF and vendors, less functionality for the users. Less functionality is a deliberate, concious choice on the part of the IETF. Fixing the problem is utterly trivial. Think of all the machines in my network as a single machine with a single IP address. The requests to open and close ports to the outside world are simply RPC requests (without the RPC syntax). That should be perfectly doable, in essence we'd be redefining the protocol and port numbers to be part of the address. However, this means these must now also be put in the DNS and in most other places where IP addresses show up. So this adds up to a HUGE amount of new work. No, the machines do not need to be individually addressable. Guess what: we already did pretty much the same thing with IPv6. The logical conclusion here is that we can save a lot of time and effort by simply adding IPv6 to the mix, as it is just a hair shy of being ready for full deployment, while all this stuff to make NAT actually work is all over the place. Simply repeating the claim that IPv6 is the solution to every issue does not make it so, or advance the deployment of IPv6. The problem is the intrinsic asymmetry between the value of an IPv4 and an IPv6 address. An IPv4 address will be visible to the world, an IPv6 address will only be visible to other IPv6 addresses. The main reason IPv6 is nowhere is the refusal to deal with NAT except by ideological reactions like the above. NAT is the way to deploy IPv6. The consumer's internal network can then be a NAT'd IPv4 net and the external network can be IPv6. In the case of H323 the problem is not just NAT, it is the derranged protocol which uses a block of 3000 odd TCP/IP ports to receive messages on. there is no way that this is consistent with good firewall management So now you are complaining because after you install a firewall, it turns out the thing does its job? No, I am complaining about a protocol that is not firewall friendly. The whole idea that decent security can be had by allowing packets with certain port numbers in them in and not others is fatally flawed, Your view is not held by the computer security industry. Sure firewalls are not infallible. But that does not mean that they do not provide a valuable service. One reason everything is migrating to Web Services is that the Web Services stack is designed to support a new generation of firewalls and expose exactly the right data at the perimeter. What we need is corporate zone alarm like functionality, where firewalls get to see which applications (and users) are trying to communicate with the outside world, rather than guess based on the port number in the packet. This would allow some very nice features such as blocking vulnerable versions of applications but allowing patched versions of the same application. That is not a bad idea. In essence it would mean extending requests to open incomming AND outgoing ports to the perimeter defense. Hey Mr firewall, this is Internet Explorer version 9.2, please allow me to connect up to port 80 on 23.43.2.2
Re: MBONE access?
A nit, perhaps, but: On Wed, 2004-03-03 at 20:17 -0800, Ole Jacobsen wrote: ..Note that Real Player is available for multiple platforms for free, .. The Linux version, last I tried [8.0.3.412], didn't include support for multicast. signature.asc Description: This is a digitally signed message part
Re: MBONE access?
At 09:51 PM 3/3/2004, Joel Jaeggli wrote: On Wed, 3 Mar 2004, Ole Jacobsen wrote: begin naive question Apart from the eating our own dogfood bit ... Most other Internet events I attend, or follow remotely, use Real audio/video, or sometimes Windows Media Player. Can anyone tell me if there are any TECHNICAL reasons why we can't do this for the IETF meetings? how about economic and poltical... In point of fact it has been done, either by reflecting sources to unicast through real servers or by simply generating additional sources. The resources to do this on an ongoing basis (namely transit) haven't been forthcoming. On the economic front, there have been offers, at least from me, to PAY for remote attendance. Let's face it, I'd have been happy to pay $500 to have access to all WG sessions and plenaries via Real Player or other Unicast mechanism in Seoul. There's just no way my company can afford the travel expenses for me to personally travel to Korea. The IETF should be interested in individuals, not just large corporations, participating. What better way than to provide a way for individuals to attend on their own budgets? If that means virtual attendance, then so be it. Multicast is just not available to many of the folks who might otherwise attend. I don't care what unicast mechanism is chosen, provided it allows a wider crosssection of the community access to live participation in the meetings. joelja Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: On supporting NAT, was: Re: MBONE access?
On 4-mrt-04, at 14:42, Hallam-Baker, Phillip wrote: There are good reasons why ISPs are encouraging their customers to use NAT, they provide a weak firewall capability and that in turn significantly reduces exposure to being hacked which in turn reduces the cost of chasing zombie machines. Hm, but apparently many ISPs don't care about their customer boxes being turned into zombies as they let them persist in their undead state for long periods of time. ISPs would probably love it if there were no NAT (or proxies, NAT is no more than a simple way to implement generic proxying), that way they could extort their customers even more. I don't think anyone has won here, there are just casualties all over the place: more work for the IETF and vendors, less functionality for the users. Less functionality is a deliberate, concious choice on the part of the IETF. Fixing the problem is utterly trivial. A pointer or two to support the former would be nice. An explanation of the latter too, as I'm unfamiliar with this trivial fix. Or are you referring to the issue that some client/server type interactions are broken when the client is behind NAT? This should probably be fixable in most cases (I wouldn't call updating huge installed bases trivial though), but that still leaves the applications and protocols that don't conform to the client/server model, such as VoIP. Think of all the machines in my network as a single machine with a single IP address. The requests to open and close ports to the outside world are simply RPC requests (without the RPC syntax). What if two boxes want to have the same port open? Believe me, you are just making the port number part of the address. Internal address allocation (your RPC w/o RPC mechanism) is only one of the issues that needs attention in this case. Guess what: we already did pretty much the same thing with IPv6. The logical conclusion here is that we can save a lot of time and effort by simply adding IPv6 to the mix, as it is just a hair shy of being ready for full deployment, while all this stuff to make NAT actually work is all over the place. Simply repeating the claim that IPv6 is the solution to every issue does not make it so, or advance the deployment of IPv6. It's annoying when people complain about a problem when the solution is right there in their face. The problem is the intrinsic asymmetry between the value of an IPv4 and an IPv6 address. An IPv4 address will be visible to the world, an IPv6 address will only be visible to other IPv6 addresses. In this case, you only need to be visible to the streaming server... Use your IPv4 address for other stuff if you like. The main reason IPv6 is nowhere is the refusal to deal with NAT except by ideological reactions like the above. NAT is the way to deploy IPv6. I don't follow. The whole idea that decent security can be had by allowing packets with certain port numbers in them in and not others is fatally flawed, Your view is not held by the computer security industry. The idea that security is a substance with an independent existance which underpins a security industry is also fatally flawed. (And one of the main reasons why I chose to avoid becoming a part of said industry.) Security is a property of all aspects of life and must be managed as such. firewalls get to see which applications (and users) are trying to communicate with the outside world, rather than guess based on the port number in the packet. That is not a bad idea. In essence it would mean extending requests to open incomming AND outgoing ports to the perimeter defense. Hey Mr firewall, this is Internet Explorer version 9.2, please allow me to connect up to port 80 on 23.43.2.2 Right! When the firewall considers IE 9.2 safe it may allow it to communicate freely, but at a later time, when a vulnerability is found and (hopefully) a new version is installed, IE 9.2 isn't allowed to connect to the rest of the world anymore, or only to trusted destinations. This mechanism would also be great to catch trojans and other unauthorized software trying to communicate over the net.
RE: On supporting NAT, was: Re: MBONE access?
Or are you referring to the issue that some client/server type interactions are broken when the client is behind NAT? This should probably be fixable in most cases (I wouldn't call updating huge installed bases trivial though), but that still leaves the applications and protocols that don't conform to the client/server model, such as VoIP. VoIP is still a client-server model when you get down to the individual communications. For that matter so is UDP. In any communication you have to have a listener waiting for attention and a party that initiates the message transfer. This happens even when you look at CSP type mechanisms where there is a symmetric rendezvous. What if two boxes want to have the same port open? Same thing that happens when two processes on the same box ask for the same port. The latecomer loses. Either that or the port is assigned on a different IP address, these could be pooled at the ISP level. That is not a problem if you know about this restriction when you design the protocol that is NAT listener friendly. You could even build into the protocol a feature that would allow a response of the type, 'the port requested is already in use by machine at address 10.2.1.1, he is accepting requests to share via protocol X on port Y' Believe me, you are just making the port number part of the address. Internal address allocation (your RPC w/o RPC mechanism) is only one of the issues that needs attention in this case. Needs attention is not the same as 'impossible'. It is very clear that the negative effects of NAT can be largely eliminated if there is goodwill and an intention to succeed. It is equally clear that the whole issue of NAT has been addressed here with a complete determination to fail. It's annoying when people complain about a problem when the solution is right there in their face. A 'solution' that requires action by parties completely out of my control does not qualify as such in my opinion. At present I don't expect much in the way of NAT deployment before 2015, and that is building in expectation of a major shakeup in the management structure in 2010. If things go on as at present I don't expect IPv6 deployed before 2025. The main reason IPv6 is nowhere is the refusal to deal with NAT except by ideological reactions like the above. NAT is the way to deploy IPv6. I don't follow. NAT performs address translation. it is in effect an Ipv4 to IPv4 translator. Make that transparent and you can make Ipv4 to IPv6 and IPv6 to Ipv4 transparent in the same way. The idea that security is a substance with an independent existance which underpins a security industry is also fatally flawed. (And one of the main reasons why I chose to avoid becoming a part of said industry.) Security is a property of all aspects of life and must be managed as such. Which is why the empirical observation that firewalls significantly reduce the number of successful penetration incidents is important. The theoretical strength of a firewall against the NSA is irrelevant when 99% of the attacks are from script kiddies. Filtering out the 99% of script kiddies allows more time to focus on the remainder. Right! When the firewall considers IE 9.2 safe it may allow it to communicate freely, but at a later time, when a vulnerability is found and (hopefully) a new version is installed, IE 9.2 isn't allowed to connect to the rest of the world anymore, or only to trusted destinations. This mechanism would also be great to catch trojans and other unauthorized software trying to communicate over the net. Yes, and sign the messages under a key protected by the trustworthy computing base. That is where Palladium gives real value. Phill
Re: MBONE access?
On the economic front, there have been offers, at least from me, to PAY for remote attendance. Let's face it, I'd have been happy to pay $500 to have access to all WG sessions and plenaries via Real Player or other Unicast mechanism in Seoul. There's just no way my company can afford the travel expenses for me to personally travel to Korea. I too would have no problem paying for this. The IETF should be interested in individuals, not just large corporations, participating. What better way than to provide a way for individuals to attend on their own budgets? If that means virtual attendance, then so be it. Exactly right. Multicast is just not available to many of the folks who might otherwise attend. I don't care what unicast mechanism is chosen, provided it allows a wider crosssection of the community access to live participation in the meetings. The choice of unicast technology is largely irrelevant to me as well. While I might find one approach somewhat more advantageous than another at this particular point in time, if something is chosen I will take the necessary steps to get it working. The same cannot be said for multicast, since no amount of my own futzing will make it work for me. Ned
Re: MBONE access?
Right, but multicast appears to be a large part of the problem. I know this is heresy, but good engineers are usually able to use available tools. It is possible to use the handle of a screwdriver to hit the head of nail and drive it into the wall --- when you don't have a hammer. Now, it was a *naive* question, and others have pointed out the cost of unicast alternatives, so I am not saying adopt commercial solutions today, but if we are only doing multicast for religious reasons AND it isn't reaching the large group of people who cannot participate THEN it might be time to consider some alternatives, that's all. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Thu, 4 Mar 2004, Frank Solensky wrote: A nit, perhaps, but: On Wed, 2004-03-03 at 20:17 -0800, Ole Jacobsen wrote: ..Note that Real Player is available for multiple platforms for free, .. The Linux version, last I tried [8.0.3.412], didn't include support for multicast.
Re: MBONE access
FWIW, I tried to participate in a couple of WG meetings this week. I had to go to work to get multicast access - efforts to set up a tunnel to my home failed (partially because there wasn't any obvious way to try it out in advance of the actual meeting). Even when I could get multicast access, I could get video but the audio would cut out after a few seconds. This was with the latest QuickTime player for the mac. I also tried VLC for the mac but that didn't work at all. We've been experimenting with this stuff for longer than I can remember. I'd like for this stuff to really be useful. Here's my list of things that I think are necessary for it to be useful: 1. We need to broadcast _every_ session, or at least most of them. That has a number of implications. It means we need more bandwidth. It might be that we would have to use fewer codecs - maybe just H.261. It might also mean that we need to set up some meeting rooms differently so that a single camera would suffice (thus removing the need for someone to switch between cameras). Comments from the floor might have to be made from the front of the room. 2. We need the ability to access these transmissions via unicast. That probably means that we need willing parties on various continents to provide tunnel endpoints and/or proxies and/or reflectors. 3. The client software needed to participate must be available to everybody. That probably means using an open source tool as the baseline. If it happens to also work with proprietary tools, so much the better. 4. It needs to be possible to test things well in advance of the meeting. By the time the meeting is underway, there's not enough time to debug tunnel setup, client problems, etc. This probably means having live video feeds set up in advance, using the same codecs and tools that will be used at the meeting. Ideally there should be feeds sourced from somewhere near the meeting site's point of attachment to the network. 5. In my limited experience, Jabber is an acceptable way for remote participants to make comments - provided there is someone willing to read those comments to those physically present at the meeting. But if this were to be a widespread practice, we'd need to have some reasonably fair way to divide time between the local participants and the remote participants. 6. We should require those who use slides to make them available for download, in a portable format, well in advance of the meeting. I realize this is a tall order. I'm trying to make a realistic statement of what it takes for remote access to meetings to be useful. (I realize it might not seem realistic to actually _do_ this, but if it's not realistic, we may as well admit it.) I suspect the problem boils down to _money_. Money would buy more bandwidth. Money would help get local tunnel/redirector/proxies set up. Money would help software development if open source tools needed to be tweaked. Money would pay for more on-site equipment and operators. If this stuff _worked_ I would be willing to pay something close to the full conference fee to attend the conference remotely, for those cases when I couldn't be there in person. Though I guess I wonder whether there would ever be enough remote participants to cover the expenses. (for that matter, if it _worked_, would lots of people stop travelling to meetings?) If it is feasible it should be possible to implement this in stages: 1. Pick an open source client. Tweak it as necessary. Set up pointers in appropriate web pages so that IETFers could easily find and download the code. Provide instructions for how to configure and use it. 2. Set up tunnel endpoints / proxies / redirectors. If it's necessary to limit access to IETFers, find a way to do this. 3. Set up live video/audio feeds. If it's necessary to limit access to IETFers, find a way to do this. 4. Encourage IETFers to download clients, test with the live feeds, and provide feedback. 5. Try this in one or two meeting rooms. Experiment with a single microphone setup in one room. Once it works, expand it gradually to include additional meeting rooms (perhaps even during the same week). 6. Once it is demonstrated to work, start charging money :)
Re: MBONE access?
On Wed, Mar 03, 2004 at 04:18:42PM -0500, Joe Abley wrote: If you find an answer, telling this list would be good. In the past the answer has been you don't, often coupled with enthusiastic statements about the mbone being in full production, and tunnels no longer being necessary. Please tell me you're kidding... I just phoned the hotline of my provider T-DSL/T-Online. They didn't even know what I was talking about. All they said is that they can't help if I'm using Linux, because that operating system is not supported. I'd have to call a 0190 number (62ct / min), which I did. Listening to the wait queue music for about 1,5 minutes. Then there was a Lady who also hasn't ever heard about this and couldn't imagine what I was talking about... Hadmut
Re: MBONE access?
On Wednesday, March 3, 2004, at 04:18 PM, Joe Abley wrote: In the past the answer has been you don't, often coupled with enthusiastic statements about the mbone being in full production, and tunnels no longer being necessary. I contacted my ISP last week about getting multicast routing configured and they spent days trying to get it working. They finally called their equipment vendor, who explained to them that they need someone to route to them, as well, which was news to them. I'm now getting an mbone feed through work (I'm a telecommuter so it wasn't automatic). You can sometimes get a multicast tunnel terminated by a friendly university department, if you've got such thing, but they're not as happy about letting you pump a lot of traffic through them as they used to be. BTW, the only multicast stream working during last night's plenary was the MPEG-1 one, and because of the high bit rate it was very lossy. The other, lower bitrate streams weren't working and the guy running the service kind of blew me off (and I quote: watch the video in a couple weeks after we get back). If the problem recurs during today's sessions, please send email to them at [EMAIL PROTECTED] so they'll see that I'm not a lone crank. Melinda
Re: MBONE access?
In addition to multicast, today we should consider other inexpensive streaming solutions available even with IPv6 support. They allow to broadcast the event with lower bandwidths for those that can't get multicast, or don't have the bandwidth to support high bit rates. Regards, Jordi - Original Message - From: Melinda Shore [EMAIL PROTECTED] To: Joe Abley [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, March 04, 2004 6:54 AM Subject: Re: MBONE access? On Wednesday, March 3, 2004, at 04:18 PM, Joe Abley wrote: In the past the answer has been you don't, often coupled with enthusiastic statements about the mbone being in full production, and tunnels no longer being necessary. I contacted my ISP last week about getting multicast routing configured and they spent days trying to get it working. They finally called their equipment vendor, who explained to them that they need someone to route to them, as well, which was news to them. I'm now getting an mbone feed through work (I'm a telecommuter so it wasn't automatic). You can sometimes get a multicast tunnel terminated by a friendly university department, if you've got such thing, but they're not as happy about letting you pump a lot of traffic through them as they used to be. BTW, the only multicast stream working during last night's plenary was the MPEG-1 one, and because of the high bit rate it was very lossy. The other, lower bitrate streams weren't working and the guy running the service kind of blew me off (and I quote: watch the video in a couple weeks after we get back). If the problem recurs during today's sessions, please send email to them at [EMAIL PROTECTED] so they'll see that I'm not a lone crank. Melinda ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: MBONE access?
On 3-mrt-04, at 22:54, Melinda Shore wrote: BTW, the only multicast stream working during last night's plenary was the MPEG-1 one, and because of the high bit rate it was very lossy. The other, lower bitrate streams weren't working and the guy running the service kind of blew me off (and I quote: watch the video in a couple weeks after we get back). I got a similar-spirited reaction after I posted this to the list on nov 18/19: As long as we're bitching about the network: would it be possible to start doing some unicast streaming of sessions in the future? Access to multicast hasn't gotten significantly better the past decade, but streaming over unicast is now routine as the codecs are so much better these days, as is typical access bandwidth. I'll happily take 40 kbps MPEG-4 audio only; the video is so badly out of sync that it is unwatchable most of the time anyway. Because I really wanted to follow yesterday's multi6 session, I arranged for some ad-hoc streaming. Kurtis Lindqvist was kind enough to provide me with an audio/video feed, which I ran through a streaming server. Despite the fact that we used a microphone built into the camera the audio was workable, although the video wasn't all that useful because of the low resolution and mounting limitations. I think we should consider streaming audio over unicast for all sessions. There are already microphones in all rooms, right? As this is only 32 kbps (you can go even lower) and any laptop with audio in and suitable software can provide the feed, and there is little or no need to attend to anything during steaming, I'm sure it's possible to work out the logistics.
Re: MBONE access?
On Wed, 3 Mar 2004, Melinda Shore wrote: BTW, the only multicast stream working during last night's plenary was the MPEG-1 one, and because of the high bit rate it was very lossy. The other, lower bitrate streams weren't working and the guy running the service kind of blew me off (and I quote: watch the video in a couple weeks after we get back). If the problem recurs during today's sessions, please send email to them at [EMAIL PROTECTED] so they'll see that I'm not a lone crank. From the places we are able able to monitor the h.261/mpeg-1/mpeg-4 were all making it to the US. but the abilene router proxy was down last night so we had less information then we would otherwise have had. It's very hard to run a camera, monitor the recording and debug someone elses network in the United States from Korea. For what it's worth I've been mirroring the recordings to our ftp server at the UO as fast as I can, the wed plenary should be there by midnight pst on wed. Melinda -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
RE: MBONE access?
I'm all for eating our own dog food, but IMO workable remote access is more important. The point about eating the dog food is so that you improve it to the point where it is acceptable. I think it is time to accept that the MBONE technology is fatally flawed and is not going to be deployable. Equally flawed and useless are the H.323 protocols that do not tunnel through NAT or even work with a firewall in a remotely acceptable fashion. This thing is not rocket science. There are lots of folk with the little cameras and the ISPs do not want to have their bandwidth wasted needlessly. But trying to do multicast in the network layer has failed. The Internet considers complexity in the network to be stupidity and does not route it. Phill
RE: MBONE access?
Equally flawed and useless are the H.323 protocols that do not tunnel through NAT or even work with a firewall in a remotely acceptable fashion. NAT is the big bad dog here, that is what breaks the end to end connectivity. restart NAT war / In case you had not noticed there are now tens of millions of NAT devices in use. End users are not going to pay $10 per month for an extra IP address when they can connect unlimited numbers of devices to the net using a $40 NAT box. The NAT war has been over for years, NAT won. The problem is that the IETF still has not come to terms with that fact. The Internet was designed to be a network of networks. The core architecture is NOT end-to-end, that is a political shiboleth that has been imposed later. The features of the Internet that work are the ones that work within the end-to-end model. The features that are failures are the ones where the end-to-end model is bogus. The security world has long since realised that exclusive relianance on end-to-end security is bogus. I don't know of any serious security professionals who now claim that firewalls are bogus or that they will go away as the myth has it. Perimeter security is here to stay. In the case of H323 the problem is not just NAT, it is the derranged protocol which uses a block of 3000 odd TCP/IP ports to receive messages on. there is no way that this is consistent with good firewall management - unless you go to some pretty sophisticated additional control to open up and shut down the ports as required. As for IPv6, the only feasible way to deploy it is by co-opting those NAT boxes. Phill
Re: MBONE access?
Most of the NAT boxes allow you to use IPv6. There are several protocols that allow it. The simpler one http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-palet-v6ops-proto41-nat-03 Regards, Jordi - Original Message - From: Hallam-Baker, Phillip [EMAIL PROTECTED] To: 'Jeroen Massar' [EMAIL PROTECTED]; Hallam-Baker, Phillip [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 04, 2004 10:44 AM Subject: RE: MBONE access? Equally flawed and useless are the H.323 protocols that do not tunnel through NAT or even work with a firewall in a remotely acceptable fashion. NAT is the big bad dog here, that is what breaks the end to end connectivity. restart NAT war / In case you had not noticed there are now tens of millions of NAT devices in use. End users are not going to pay $10 per month for an extra IP address when they can connect unlimited numbers of devices to the net using a $40 NAT box. The NAT war has been over for years, NAT won. The problem is that the IETF still has not come to terms with that fact. The Internet was designed to be a network of networks. The core architecture is NOT end-to-end, that is a political shiboleth that has been imposed later. The features of the Internet that work are the ones that work within the end-to-end model. The features that are failures are the ones where the end-to-end model is bogus. The security world has long since realised that exclusive relianance on end-to-end security is bogus. I don't know of any serious security professionals who now claim that firewalls are bogus or that they will go away as the myth has it. Perimeter security is here to stay. In the case of H323 the problem is not just NAT, it is the derranged protocol which uses a block of 3000 odd TCP/IP ports to receive messages on. there is no way that this is consistent with good firewall management - unless you go to some pretty sophisticated additional control to open up and shut down the ports as required. As for IPv6, the only feasible way to deploy it is by co-opting those NAT boxes. Phill ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: MBONE access?
begin naive question Apart from the eating our own dogfood bit ... Most other Internet events I attend, or follow remotely, use Real audio/video, or sometimes Windows Media Player. Can anyone tell me if there are any TECHNICAL reasons why we can't do this for the IETF meetings? Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj
Re: MBONE access?
Agree. I didn't wanted to mention specific brands before, but we use Windows Media Server for our own events (www.ipv6-es.com), and it works very well (with IPv6 support) I volunteer to help if needed. Regards, Jordi - Original Message - From: Ole Jacobsen [EMAIL PROTECTED] To: JORDI PALET MARTINEZ [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, March 04, 2004 11:30 AM Subject: Re: MBONE access? begin naive question Apart from the eating our own dogfood bit ... Most other Internet events I attend, or follow remotely, use Real audio/video, or sometimes Windows Media Player. Can anyone tell me if there are any TECHNICAL reasons why we can't do this for the IETF meetings? Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: MBONE access?
In message [EMAIL PROTECTED], Ole Jacobsen wr ites: begin naive question Apart from the eating our own dogfood bit ... Most other Internet events I attend, or follow remotely, use Real audio/video, or sometimes Windows Media Player. Can anyone tell me if there are any TECHNICAL reasons why we can't do this for the IETF meetings? Does Windows Media Player run on a high-enough percentage of IETFers machines? The incidence of Windows here is considerably lower than in the population as a whole. Note that this is a technical reason: it doesn't support our user base. --Steve Bellovin, http://www.research.att.com/~smb
RE: MBONE access?
On Wed, 3 Mar 2004, Hallam-Baker, Phillip wrote: I'm all for eating our own dog food, but IMO workable remote access is more important. The point about eating the dog food is so that you improve it to the point where it is acceptable. I think it is time to accept that the MBONE technology is fatally flawed and is not going to be deployable. There is nothing wrong with Mbone, per se--though, as someone mentioned, it might be nice to have better codecs. The problem is that multicast is flawed, and not going to be globally deployable. It will be useful perhaps to the large organization that has a potential for multicast. But it certainly isn't useful in any potentially hostile environment. To abuse some more buzzwords, multicast is not a global technology. Its more an enterprise technology. Or, as MBone is today, arranged as tunnels to participating and interested organizations. Equally flawed and useless are the H.323 protocols that do not tunnel through NAT or even work with a firewall in a remotely acceptable fashion. There is nothing wrong with h323. There are good reasons for the IP address of the client to be embedded in some h323 control messages. In most cases, this is a good thing, and an advantage for call control and call routing systems. Indeed, this is what gives h323 its scalability and ability to compete and work in tandem with the PSTN. But when passing through a NAT, those addresses and port numbers have to be properly and statefully translated---That's what a proxy does. The problem is that your NAT doesn't (or most likely, /didn't/ until the last year or two or three) support h323 proxy. You need h323 proxy support just like you need proxy support for many non-trivial protocols. Either upgrade your NAT software, or if you run linux/bsd/etc, install an open source h323 proxy on your NAT gateway. This thing is not rocket science. There are lots of folk with the little cameras and the ISPs do not want to have their bandwidth wasted needlessly. But trying to do multicast in the network layer has failed. The Internet considers complexity in the network to be stupidity and does not route it. Perhaps. But it didn't fail because it was too complex. Failed probably isn't the right word. Adopted or Allowed are probably more appropriate. It isn't allowed by ISPs because it isn't suitable to the environment. It may be allowed by cooperating organizations, which have to create tunnels between them. I don't a big problem with that. --Dean
Re: MBONE access?
Actually, the use of Windows Media Player is quite rare for the events I am talking about, Real is probably used in 90% of them, I only mentioned the other one because it does appear from time to time. Note that Real Player is available for multiple platforms for free, and so is Windows Media Player, I have one for the Mac for example. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Thu, 4 Mar 2004, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Ole Jacobsen wr ites: begin naive question Apart from the eating our own dogfood bit ... Most other Internet events I attend, or follow remotely, use Real audio/video, or sometimes Windows Media Player. Can anyone tell me if there are any TECHNICAL reasons why we can't do this for the IETF meetings? Does Windows Media Player run on a high-enough percentage of IETFers machines? The incidence of Windows here is considerably lower than in the population as a whole. Note that this is a technical reason: it doesn't support our user base. --Steve Bellovin, http://www.research.att.com/~smb
Re: MBONE access?
Paul, This is simply silly. What you are saying is that for religious reasons you are unwilling to use FREE and widely used tools in order to help us develop our own. Next thing you'll be telling me PDF is a bad thing. If you want the IETF to be a place where more people can participate you need to ditch some of this religion. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Wed, 4 Mar 2004, Paul Vixie wrote: Apart from the eating our own dogfood bit ... apart from that, we should all stay at our desks and use DECNet-PhaseV or NetWare to get our work done, and stop trying to create new protocols that are robust, interoperable, and open. in other words there is a big nothing apart from that particular thing. the fact that realmedia and windowsmedia aren't interoperable means that we (this community) failed to recognize and address a common need, and that the world (including this community) is suffering for it. compounding this failure by adopting proprietary technology for the primary work of this community -- which is interior and published communications -- would be a bad, bad (bad) thing. -- Paul Vixie
RE: MBONE access?
So we are still faced with the question of how to deploy multicast to the end user. Sad. I have two circuits running into my home office, and both providers (one a major telco) are so cranially-rectally inverted that they have no clue what multicast is much less how to deploy it. What does it take, someone to go to berkeley and hack a server onto the network to act as a tunnel broker? Scott On Wed, 3 Mar 2004, Dean Anderson wrote: On Wed, 3 Mar 2004, Hallam-Baker, Phillip wrote: I'm all for eating our own dog food, but IMO workable remote access is more important. The point about eating the dog food is so that you improve it to the point where it is acceptable. I think it is time to accept that the MBONE technology is fatally flawed and is not going to be deployable. There is nothing wrong with Mbone, per se--though, as someone mentioned, it might be nice to have better codecs. The problem is that multicast is flawed, and not going to be globally deployable. It will be useful perhaps to the large organization that has a potential for multicast. But it certainly isn't useful in any potentially hostile environment. To abuse some more buzzwords, multicast is not a global technology. Its more an enterprise technology. Or, as MBone is today, arranged as tunnels to participating and interested organizations. Equally flawed and useless are the H.323 protocols that do not tunnel through NAT or even work with a firewall in a remotely acceptable fashion. There is nothing wrong with h323. There are good reasons for the IP address of the client to be embedded in some h323 control messages. In most cases, this is a good thing, and an advantage for call control and call routing systems. Indeed, this is what gives h323 its scalability and ability to compete and work in tandem with the PSTN. But when passing through a NAT, those addresses and port numbers have to be properly and statefully translated---That's what a proxy does. The problem is that your NAT doesn't (or most likely, /didn't/ until the last year or two or three) support h323 proxy. You need h323 proxy support just like you need proxy support for many non-trivial protocols. Either upgrade your NAT software, or if you run linux/bsd/etc, install an open source h323 proxy on your NAT gateway. This thing is not rocket science. There are lots of folk with the little cameras and the ISPs do not want to have their bandwidth wasted needlessly. But trying to do multicast in the network layer has failed. The Internet considers complexity in the network to be stupidity and does not route it. Perhaps. But it didn't fail because it was too complex. Failed probably isn't the right word. Adopted or Allowed are probably more appropriate. It isn't allowed by ISPs because it isn't suitable to the environment. It may be allowed by cooperating organizations, which have to create tunnels between them. I don't a big problem with that. --Dean sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/
Re: MBONE access?
What you are saying is that for religious reasons you are unwilling to use FREE and widely used tools in order to help us develop our own. well, actually, that's not what i said at all. Next thing you'll be telling me PDF is a bad thing. and no, that won't be the next thing i'll tell you. If you want the IETF to be a place where more people can participate you need to ditch some of this religion. if there were no robust open alternatives i'd be the first to say issue an rfp.
Re: MBONE access?
On Wed, 3 Mar 2004, Ole Jacobsen wrote: What you are saying is that for religious reasons you are unwilling to use FREE and widely used tools in order to help us develop our own. The focus in clients is a little misguided... There's a reasonable cross-section of clients for most platforms the supports a set of mostly interoperable codecs and transports. It is possible to source with real/darwin streaming server/videolan a source that will be visbile to users of quicktime/real/vlc and some other clients via multicast or unicast transports. In order to do that you have to be somewhat selective about which codecs, and features you use. The transport is an issue. 500Kb/s isma mpeg-4 streams have a real cost if you want 200 of them... If you want variable-rate codecs that support clients at an number of rates simultaniously you may have to forgoe interoperabilty in favor of a single client platform. If you want slides and video in seperate windows you need smil but there are no interoperable smil implementations. The thing I consider most unworkable frankly is low-bitrate video... I don't consider a 40 80 100Kb/s streams terribly usable regardless of the codec chosen, I want to be able to read the slides, I want to be able hear the speakers from someplace other than the bottom a barrel and I want to be able to discern who's standing at the mic. Next thing you'll be telling me PDF is a bad thing. I have deep ambivalence towards pdf but that's a seperate issue for a different forum. If you want the IETF to be a place where more people can participate you need to ditch some of this religion. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Wed, 4 Mar 2004, Paul Vixie wrote: Apart from the eating our own dogfood bit ... apart from that, we should all stay at our desks and use DECNet-PhaseV or NetWare to get our work done, and stop trying to create new protocols that are robust, interoperable, and open. in other words there is a big nothing apart from that particular thing. the fact that realmedia and windowsmedia aren't interoperable means that we (this community) failed to recognize and address a common need, and that the world (including this community) is suffering for it. compounding this failure by adopting proprietary technology for the primary work of this community -- which is interior and published communications -- would be a bad, bad (bad) thing. -- Paul Vixie -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: MBONE access?
Paul, As has been pointed out, this is a little more complicated than just the choice of client, in particular multicast is not widely available to the average Internet user. But I still find it ironic that I can watch a webcast from an ICANN meeting but I am unable to do the same for an IETF meeting (until after the fact). That is but one example. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Thu, 4 Mar 2004, Paul Vixie wrote: What you are saying is that for religious reasons you are unwilling to use FREE and widely used tools in order to help us develop our own. well, actually, that's not what i said at all. Next thing you'll be telling me PDF is a bad thing. and no, that won't be the next thing i'll tell you. If you want the IETF to be a place where more people can participate you need to ditch some of this religion. if there were no robust open alternatives i'd be the first to say issue an rfp.
Re: MBONE access?
As has been pointed out, this is a little more complicated than just the choice of client, in particular multicast is not widely available to the average Internet user. that could be punctuated very differently and thus become even more factual. But I still find it ironic that I can watch a webcast from an ICANN meeting but I am unable to do the same for an IETF meeting (until after the fact). That is but one example. well, let's do what we always do, then... have a BOF about it. we can wire a 1394 camera to jabber somehow, but until there's widely deployed idmr or a whole lot of widely deployed open/shared L4 streamsplitters, this won't be a protocol problem (like it ought to be). for dark humour value, i note with dispair that in 1992 when i participated in a project at DEC (r.i.p.) to move the nasdaq trading system onto tcp/ip, we were told by several people that ya oughta use multicast. my part of the project was an L4 streamsplitter that was used because multicast didn't work. folks told us that we'd regret it and have to tear it out in a year or two when multicast became widely deployed. someone, somewhere, is probably still using DECrbs because for them, multicast still isn't a realistic possibility. -- Paul Vixie
Re: MBONE access?
Yes, even there are other interoperable implementations for Linux and BSD based platforms. - Original Message - From: Steven M. Bellovin [EMAIL PROTECTED] To: Ole Jacobsen [EMAIL PROTECTED] Cc: JORDI PALET MARTINEZ [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 04, 2004 11:45 AM Subject: Re: MBONE access? In message [EMAIL PROTECTED], Ole Jacobsen wr ites: begin naive question Apart from the eating our own dogfood bit ... Most other Internet events I attend, or follow remotely, use Real audio/video, or sometimes Windows Media Player. Can anyone tell me if there are any TECHNICAL reasons why we can't do this for the IETF meetings? Does Windows Media Player run on a high-enough percentage of IETFers machines? The incidence of Windows here is considerably lower than in the population as a whole. Note that this is a technical reason: it doesn't support our user base. --Steve Bellovin, http://www.research.att.com/~smb ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: MBONE access?
Well we can use tools like Helix that combine Multicast, Real and Windows Media, I believe, into a single platform, so any kind of client can access it. - Original Message - From: Ole Jacobsen [EMAIL PROTECTED] To: Steven M. Bellovin [EMAIL PROTECTED] Cc: JORDI PALET MARTINEZ [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 04, 2004 1:17 PM Subject: Re: MBONE access? Actually, the use of Windows Media Player is quite rare for the events I am talking about, Real is probably used in 90% of them, I only mentioned the other one because it does appear from time to time. Note that Real Player is available for multiple platforms for free, and so is Windows Media Player, I have one for the Mac for example. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Thu, 4 Mar 2004, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Ole Jacobsen wr ites: begin naive question Apart from the eating our own dogfood bit ... Most other Internet events I attend, or follow remotely, use Real audio/video, or sometimes Windows Media Player. Can anyone tell me if there are any TECHNICAL reasons why we can't do this for the IETF meetings? Does Windows Media Player run on a high-enough percentage of IETFers machines? The incidence of Windows here is considerably lower than in the population as a whole. Note that this is a technical reason: it doesn't support our user base. --Steve Bellovin, http://www.research.att.com/~smb ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
A/V services for the IETF (was: Re: MBONE access?)
Ole, the multicast services are provided by the UOregon team supported by a grant from Cisco (+ some support from ISOC via the IETF Chair's fund). This grant is in its final year, and the end of the grant is a convenient time to stop and reconsider exactly what services we (the IETF community) want in the area of A/V at meetings, and see how we can arrange to have that done, and cover the costs. So yes, it's on my list of things to worry about - it's just not at the top.. Harald --On 3. mars 2004 18:30 -0800 Ole Jacobsen [EMAIL PROTECTED] wrote: begin naive question Apart from the eating our own dogfood bit ... Most other Internet events I attend, or follow remotely, use Real audio/video, or sometimes Windows Media Player. Can anyone tell me if there are any TECHNICAL reasons why we can't do this for the IETF meetings?
RE: MBone (virus on sniffers.pdf file download)
gm From: Gary E. Miller [mailto:[EMAIL PROTECTED]] gm Sent: Monday, September 23, 2002 2:24 PM gm Here is a link to how it is done: gm http://dhar.homelinux.com/dhar/downloads/Sniffers.pdf gm Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gm [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 Just a note: yesterday my attempt to follow the link above from (I know, it was my stupidity) Microsoft Outlook lead to my machine being (unsuccessfully) attacked by the virus Norton calls JS.Exception.Exploit. Attempts today to download that PDF file in a more properly controlled fashion fail with the file not available. Just a note for the archives and a word of warning. Jim Davis Agilent Technologies
Re: MBone
Gary E. Miller wrote: Yo Joe! On Fri, 13 Sep 2002, Joe Touch wrote: Without a dobut you are right, though I think the degree of difference is awful small. Through hosts with root on switches or through wireless into the mix and you are back to being roughly equivalent. Hosts with root can't snoop anything but broadcast UDP on switches unless the switch is configurable; many switches aren't. root has no problem seeing adjacent UDP even on a switch. Just overflow the arp cache or poison it. That all presumes the switch doesn't detect this as an attack and shutdown that link, which is an entirely reasonable reaction. Using a switch doesn't ensure security, but using multicast basically ensures promiscuity (since non-multicast capable switches are more common). joe
Re: MBone
Gary E. Miller wrote: Yo Joe! On Mon, 23 Sep 2002, Joe Touch wrote: root has no problem seeing adjacent UDP even on a switch. Just overflow the arp cache or poison it. That all presumes the switch doesn't detect this as an attack and shutdown that link, which is an entirely reasonable reaction. resonable yes, practical, no. The only way I know to prevent this is to hard code the MACs on the switch. This is time consuming to install and to maintain. It's sufficient to have the switch detect high rates of change, or large numbers of MAC addresses as an attack. That's practical enough. Barring that, please name ONE switch, or cite ONE credible reference source, where arpspoofing is prevented at the switch by any means short of harcoding the MACs. Practical != economical. Further, there are MACs which are hardcoded (i.e. to prevent overwrite of MAC addresses). What I said was that it was EASY to get at multicast, not that it wasn't impossible to get at unicast. Joe
Re: MBone
Kevin C. Almeroth wrote: Multicast is necessarily a LOT weaker: 1) I can get a copy of packets by normal operation (join a group). there is no equivalent for UDP, notably for paths that aren't shared. Again, not in all cases. You over-simplify the effectiveness of scoping. Scoping, like TTL, can limit the visibility of packet outside a boundary, but cannot do much about other users inside that boundary. PS - how can you know that the scope of ALL multicast exit paths have been properly scoped to limit access outside of some physical locale? You can't have it both ways. Yes, there is a situation where you can obtain a copy of a multicast packet through standard operation. But the fact that scoping and addressing make it non-trivial and the fact that normal operation doesn't prevent you from snooping UDP packets shrinks the gap from a LOT weaker. And as I said before, if data security is important, effectively there is no gap. Users without root can run programs that listen to multicast addresses. If that user is inside the scope boundary, game over. As I said, weakER. IMO, still quite a lot weaker than unicast. 2) UDP has application, network, and tunnel encryption that is both widely deployed and widely used. there is no equivalent for multicast. I disagree... a number of commercial multicast apps have encryption. Don't try and argue now that some relative percentage of multicast apps have less encryption than unicast apps. You're comparing a protocol that has been around a lot longer than multicast and trying to make an apples-to-apples comparison based on less availability. I can argue relative percentages just fine; we're talking about strength today, not 'strength after X years of deployment'. And for the record, multicast is UDP. As I was using it, agreed. (there are other protocols that use multicast as well) Joe
Re: MBone
Joe Touch wrote: Gary E. Miller wrote: ... Barring that, please name ONE switch, or cite ONE credible reference source, where arpspoofing is prevented at the switch by any means short of harcoding the MACs. Practical != economical. Further, there are MACs which are hardcoded (i.e. to prevent overwrite of MAC addresses). PS - as I also raised on private email earlier, some ISPs definitely hardcode which MAC can attach to a port (i.e., they lock on the first one that gets there, and prevent subsequent ones until there's an override). Specific case: Santa Barbara, Cox ISP.
Re: MBone
Matt Crawford wrote: Barring that, please name ONE switch, or cite ONE credible reference source, where arpspoofing is prevented at the switch by any means short of harcoding the MACs. Never mind, even hard-coding the MACs to the right ports doesn't solve the problem. Eve on port X can keep up a steady stream of ARP replies to Alice on port Y and Bob on port Z, telling each that the MAC address corresponding to their intended peer is that of Eve's machine. It works even if Alice and Bob are both on port Y. Now Eve has to guess 32 bits, which is de-facto harder than guessing a multicast address of 28 bits. Further, again, this assumes the switch complies. Some switches at ISPs reject ARP traffic from the port altogether, generating it internally instead. Joe
Re: MBone
Kevin C. Almeroth wrote: It only requires being on a non-IGMP'd switch or a hub; at that point, you can snoop the traffic and see any packet going to any multicast group. It's much harder to snoop UDP; for non-broadcast, you'd have to be in-line (on the wire, effectively) or on a hub. While hubs are becoming less common, they're often being replaced with cheaper non-IGMP-capable switches. Which means that they're still hubs, as far as multicast traffic is concerned. Without a dobut you are right, though I think the degree of difference is awful small. Through hosts with root on switches or through wireless into the mix and you are back to being roughly equivalent. Hosts with root can't snoop anything but broadcast UDP on switches unless the switch is configurable; many switches aren't. However, for any reasonable content provider the difference shouldn't matter. If you have sensitive/valuable content, whether it is unicast or multicast, it should be protected. To say that multicast isn't being used because there isn't security is a non-sequitor. There certainly may be more immediate concerns (scalability, accounting, etc.), but that doesn't mean security isn't a concern. Better yet, try RFC3171. Bottom-line: there are weak links in the chain. But, if those weak links weren't there, other links would be weak links, and THOSE weak links would still be weak enough to require using encryption. It just so happens that the weak multicast links are only a bit weaker than the unicast links. Understand that convoluted logic? :-) Not quite; as Valdis observes. Multicast is necessarily a LOT weaker: 1) I can get a copy of packets by normal operation (join a group). there is no equivalent for UDP, notably for paths that aren't shared. 2) UDP has application, network, and tunnel encryption that is both widely deployed and widely used. there is no equivalent for multicast. Joe
Re: MBone
Multicast is necessarily a LOT weaker: 1) I can get a copy of packets by normal operation (join a group). there is no equivalent for UDP, notably for paths that aren't shared. Again, not in all cases. You over-simplify the effectiveness of scoping. You can't have it both ways. Yes, there is a situation where you can obtain a copy of a multicast packet through standard operation. But the fact that scoping and addressing make it non-trivial and the fact that normal operation doesn't prevent you from snooping UDP packets shrinks the gap from a LOT weaker. And as I said before, if data security is important, effectively there is no gap. 2) UDP has application, network, and tunnel encryption that is both widely deployed and widely used. there is no equivalent for multicast. I disagree... a number of commercial multicast apps have encryption. Don't try and argue now that some relative percentage of multicast apps have less encryption than unicast apps. You're comparing a protocol that has been around a lot longer than multicast and trying to make an apples-to-apples comparison based on less availability. And for the record, multicast is UDP. -Kevin
Re: MBone
Kevin C. Almeroth wrote: Multicast is necessarily a LOT weaker: 1) I can get a copy of packets by normal operation (join a group). there is no equivalent for UDP, notably for paths that aren't shared. Again, not in all cases. You over-simplify the effectiveness of scoping. Unicast has TTLs too. You can't have it both ways. Yes, there is a situation where you can obtain a copy of a multicast packet through standard operation. But the fact that scoping and addressing make it non-trivial Agreed - scoping sets some boundaries, but it's primitive as a 'security' mechanism, because everyone within those boundaries can very easily get a backet. The same is just not nearly as true for unicast. 2) UDP has application, network, and tunnel encryption that is both widely deployed and widely used. there is no equivalent for multicast. I disagree... a number of commercial multicast apps have encryption. Agreed. What I am asserting (by the above) is that security is clearly important to the average user, and that the average user won't accept obfuscation as a solution. Joe
Re: MBone
Yo Joe! On Fri, 13 Sep 2002, Joe Touch wrote: Without a dobut you are right, though I think the degree of difference is awful small. Through hosts with root on switches or through wireless into the mix and you are back to being roughly equivalent. Hosts with root can't snoop anything but broadcast UDP on switches unless the switch is configurable; many switches aren't. root has no problem seeing adjacent UDP even on a switch. Just overflow the arp cache or poison it. Here is a link to how it is done: http://dhar.homelinux.com/dhar/downloads/Sniffers.pdf The dsniff package includes tools for this purpose: http://monkey.org/~dugsong/dsniff/ RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
Re: MBone
Yo Joe! On Mon, 23 Sep 2002, Joe Touch wrote: root has no problem seeing adjacent UDP even on a switch. Just overflow the arp cache or poison it. That all presumes the switch doesn't detect this as an attack and shutdown that link, which is an entirely reasonable reaction. resonable yes, practical, no. The only way I know to prevent this is to hard code the MACs on the switch. This is time consuming to install and to maintain. Barring that, please name ONE switch, or cite ONE credible reference source, where arpspoofing is prevented at the switch by any means short of harcoding the MACs. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
Re: MBone
On Fri, 13 Sep 2002 08:06:25 PDT, Joe Touch said: Hosts with root can't snoop anything but broadcast UDP on switches unless the switch is configurable; many switches aren't. Unfortunately, this isn't actually true - unless you've nailed down the switch with a hardwired MAC-address-per-port configuration, you can get it to cough up other people's data. The canonical brute force method is to simply flood the poor switch's ARP cache and sniff the traffic while it's learning. Snooping around the various repositories of such tools would find more subtle ways of doing it -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg08983/pgp0.pgp Description: PGP signature
Re: MBone
Barring that, please name ONE switch, or cite ONE credible reference source, where arpspoofing is prevented at the switch by any means short of harcoding the MACs. Never mind, even hard-coding the MACs to the right ports doesn't solve the problem. Eve on port X can keep up a steady stream of ARP replies to Alice on port Y and Bob on port Z, telling each that the MAC address corresponding to their intended peer is that of Eve's machine. It works even if Alice and Bob are both on port Y.
Re: MBone
Yo Joe! On Mon, 23 Sep 2002, Joe Touch wrote: PS - as I also raised on private email earlier, some ISPs definitely hardcode which MAC can attach to a port (i.e., they lock on the first one that gets there, and prevent subsequent ones until there's an override). Specific case: Santa Barbara, Cox ISP. I will bet $20 that COX does it on the Cable modem and not the switch. uncapping cable modems to get around the MAC limit is getting pretty common these days. See: http://www.cablemodemhack.com/ RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
Re: MBone
Date:Mon, 23 Sep 2002 17:58:21 -0500 From:Matt Crawford [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Eve on port X can keep up a steady stream of ARP | replies to Alice on port Y and Bob on port Z, telling each that the | MAC address corresponding to their intended peer is that of Eve's | machine. It works even if Alice and Bob are both on port Y. But this one is visible at the end nodes, which makes it a stretch on snooping... All the end node needs to do is treat a gratuitous ARP reply as a hint to send a new ARP request, instead of using it to replace the ARP cache (don't most people do that these days?) There's nothing Eve can do to prevent Alice from replying to Bob's ARP query, so either Eve keeps quiet, and so doesn't get packets, or Eve also replies, and Bob sees two different ARP replies - which is a sure sign of something bogus happening (more like cannon fire announcing the charge, than someone snooping on what is happening). kre
Re: Mbone question: the multicast addresses
Sorry, I could not find an answer or a pointer through http://www.ietf.org/meetings/multicast.html My provider said that it supports mbone, but only enable it on demand for specific addresses. Therefore, could anyone please inform me the multicast group addresses of the coming 47th IETF? Chan 1 audio 224.0.1.11/21010 Chan 1 video 224.0.1.12/61010 Whiteboard 224.0.1.13/41010 Chan 2 audio 224.0.1.14/21020 Chan 2 video 224.0.1.15/61020 I included ports too... also just advertised the sessions from UCSB... will be up until the Adelaide folks get their connectivity working. -Kevin
