RE: Information on Voice Over IP
Title: RE: Information on Voice Over IP here you are http://www.fokus.gmd.de/research/cc/glone/projects/ipt/ http://www.tsufl.edu/williams/Projects/InternetPhone/TSCIS445.htm http://www.cis.ohio-state.edu/~jain/refs/ref_voip.htm -Original Message- From: Sarika Gupta [mailto:[EMAIL PROTECTED]] Sent: jeudi 9 mars 2000 07:36 To: [EMAIL PROTECTED] Subject: Information on Voice Over IP Dear Sirs and Madams, I need information on Voice over IP for one of the technical papers which I'll be presenting. Could anyone point to really good sites for that? Thanks regds, Sarika
Re: Re: Critically compare the congestion control on TCP/IP and ATM
Dear Sir/Madam, Thank you all for giving me so much information! I have read some, and almost get a clear idea of how ATM manage the congestion control. But I still get one question: generally speaking, TCP/IP is equal to the transport and network layer in the OSI model, and it seems that the ATM works on the Data Link Layer (?). They serve different function in the OSI model. Through they all have congestion control facility, how to compare mechanism in different layer? Does the topic "Critically compare the congestion control on TCP/IP and ATM" mean only compare of the algorithms of them? Thank you again for you valuable help! rgds, Truly yours, Jianbo Huang :-)
Re: Information on Voice Over IP
Michael Stilmant wrote: here you are http://www.fokus.gmd.de/research/cc/glone/projects/ipt/ http://www.tsufl.edu/williams/Projects/InternetPhone/TSCIS445.htm http://www.cis.ohio-state.edu/~jain/refs/ref_voip.htm See also http://www.cs.columbia.edu/sip http://www.cs.columbia.edu/~hgs/internet -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs
history
i was looking thru some old archives (1982 on - yes, thats right, from just before this years college kids were born) of the original tcp-ip maillist and came across a message from mark crispin about a broken vax mailer flooding neighbor mailservers with SYNs..amazing how nothings new see http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/ for a slightly incomplete archive of it all i couldn't find any other archive but if someoen does have it, let me know and i'll delete mine and point at theirs... one interesting thing is to look at pre-DNS email addresses - so there used to be this single file we'd all FTP from ISI with the hosts.txt listing of name/addresses - then one day we distributed itnow of course has to haev a .com, and the nameservers have to zone xfer it all the time tooso plus ca change, plus c'est le mome raths cheers jon
RE: Re[2]: Re: Critically compare the congestion control on TCP/
I recall that Larry Roberts a few years ago gave presentations (at NetWorld+InterOp ?) that compared the congestion avoidance algorithms of ATM-ABR service to TCP/IP. I know he has started a new company since then and I do not have any contact information. Regards, Dell. __ Dell Schipper Phone: (214) 495-6422 Advanced Network Solutions Fax: (214) 495-6219 Fujitsu Network Services[EMAIL PROTECTED] __
RE: Re[2]: Re: Critically compare the congestion control on TCP/
At 11:16 AM 03/09/2000 -0600, Schipper, Dell wrote: I recall that Larry Roberts a few years ago gave presentations (at NetWorld+InterOp ?) that compared the congestion avoidance algorithms of ATM-ABR service to TCP/IP. I know he has started a new company since then and I do not have any contact information. One of my favorites along those lines was: "End-to-End Traffic Management Issues in IP/ATM Internetworks," draft-jagan-e2e-traf-mgmt-00.txt, S. Jagannath and N. Yin, August 1997. - paul [snip] Abstract This document addresses the end-to-end traffic management issues in IP/ATM internetworks. In the internetwork environment, the ATM control mechanisms (e.g., Available Bit Rate (ABR) and UBR with Early Packet Discard (EPD)) are applicable to the ATM subnetwork, while the TCP flow control extends from end to end. We investigated the end to end performance in terms of TCP throughput and file transfer delay in cases using ABR and UBR in the ATM subnetwork. In this document, we also discuss the issue of trade-off between the buffer requirements at the ATM edge device (e.g., Ethernet-ATM switch, ATM router interface) versus ATM switches inside the ATM network. Our simulation results show that in certain scenarios (e.g., with limited edge device buffer memory) UBR with EPD may perform comparably to ABR or even outperform ABR. We show that it is not sufficient to have a lossless ATM subnetwork from the end-to-end performance point of view. The results illustrate the necessity for an edge device congestion handling mechanism that can couple the ABR and TCP feedback control loops. We present an algorithm that makes use of the ABR feedback information and edge device congestion state to make packet dropping decisions at the edge of the ATM network. Using the algorithm at the edge device, the end-to-end performance in throughput and delay are improved while using ABR as the ATM subnetwork technology and with small buffers in the edge device. [snip]
Re: history
Jon, Sigh ... I checked out the archive and noticed my own email in the fall 82 archive, from when I was managing the NCP to TCP transition on the ARPANET (I wrote the code to disable NCP at the IMP interface). I didn't need to be reminded how long I've been doing this stuff ... :-). Cheers, Andy == At 03:11 PM 3/9/00 +, Jon Crowcroft wrote: i was looking thru some old archives (1982 on - yes, thats right, from just before this years college kids were born) of the original tcp-ip maillist and came across a message from mark crispin about a broken vax mailer flooding neighbor mailservers with SYNs..amazing how nothings new see http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/ for a slightly incomplete archive of it all i couldn't find any other archive but if someoen does have it, let me know and i'll delete mine and point at theirs... one interesting thing is to look at pre-DNS email addresses - so there used to be this single file we'd all FTP from ISI with the hosts.txt listing of name/addresses - then one day we distributed itnow of course has to haev a .com, and the nameservers have to zone xfer it all the time tooso plus ca change, plus c'est le mome raths cheers jon - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand. Andrew G. Malis [EMAIL PROTECTED] phone:978 952-7414 fax:978 392-2074 Lucent Technologies 1 Robbins RoadWestford, MA 01886
Suggestion for Automated Security Information
This is just to "put the feelers out" with regards to security bug fixes / alerts / workarounds and the automation of receiving this type of information. Given any heterogeneous environment, platform or network, an administrator/security professional often needs to keep track of multiple OS bug lists. In addition to these lists, there are a number of applications running on these OS's whose lists must also be monitored for security alerts and fixes. A primary concern in the security field is that as soon as a fix is identified, or a vulnerability is identified, it is more than likely that it is already being exploited. Any further delay in fixing the problem, patching your OS for example only increases the vulnerability of your environment. My suggestion is to create an Internet Database where vendors / Emergency Response Teams, may put information in a SPECIFIC format regarding security alerts etc. Each vendor could be issued with a bit pattern representing them, and they may then implement their own bit pattern representing their various products. Then when an alert / fix or whatever becomes available they enter details into this database, using both the vendor an product pattern. The two patterns combined would uniquely identify a product. The overall effect would enable automation to be written that could query this database ( perhaps simple SQL ) and inform you when one of the products that you manage has a defect of some sort. Further, it could be extended to download the fixes identified, even install them. Of course there are security considerations in any venture such as this. For example, each entry in the database would have to be digitally signed to avoid unscrupulous people from adding false information, or trojan "fixes" for example. Assignment of vendor ID's should be managed centrally, like IANA did for example. This is only the tip of the iceberg of possibilities and ideas, but I would love to know what others think about this.. together the net can be a safe place. Monitoring your emails because you subscribed to 70 different bug-traq esque lists is OK, but an automated alerting system ( as this could easily become ) would be less infallible ( hmm is that even a proper sentence? ) I nickname this 'CRAAB' - Common Repository for Advisories/Alerts and Bulletins Anyway - what do you thing Garreth J Jeremiah.
Re: Who is interested in wireless cards for the Adelaide IETF meeting?
At 04:08 PM 3/4/00 -0500, Marcus Leech wrote: Bill Sommerfeld wrote: I hope the 128 bit "gold" cards use a longer IV.. - Bill Does anyone know if the 128-bit variant of WEP is openly specified anywhere? The last I heard RC4 was owned by RSA and not exactly open. But I do have a PDF file describing Lucent's WEP implementation a layer above RC4, so it covers some of the key management details. If you really need it, let me know. Also you can read the encryption section of 802.11 With the spinoff of the Enterprise portion of Lucents business, will the 128-bit variant quietly die? I hope not (assuming that it's any good, of course). Certainly not. But as someone else mentioned, there are U.S. laws or regulations restricting sales of 128-bit encryption overseas. So I kind of doubt it will be enabled on the base stations in Adelaide. But I suppose you can purchase such cards in the U.S. and they will work fine in Adelaide with encryption turned off. As for pricing, note that the price for the cards that will be sold in Adelaide are in Australian dollars which are valued quite differently than U.S. dollars. Disclaimer: I am neither a lawyer or a crypto expert. Nor do I work in the Wavelan division of Lucent. I'm just lamely trying to help.
MMDS knowledge
Hi all I like to know whether anyone has address MMDS deployed within your enviroment. Pls let me know if you are able to provide me some information on this technology. regards mano Thanks and Best Regards Have a Good Day Manohar Menon Fixed Network Planning Products Plot 12155 ( Lot 13), Jalan Delima 1/1, Subang Hi-Tech Ind. Est Park 4 Shah Alam Selangor Malaysia Tel : 006 03 580 1967 Fax : 006 03 580 1412 Matt Holdrege [EMAIL PROTECTED] 03/10 10:29 AM At 04:08 PM 3/4/00 -0500, Marcus Leech wrote: Bill Sommerfeld wrote: I hope the 128 bit "gold" cards use a longer IV.. - Bill Does anyone know if the 128-bit variant of WEP is openly specified anywhere? The last I heard RC4 was owned by RSA and not exactly open. But I do have a PDF file describing Lucent's WEP implementation a layer above RC4, so it covers some of the key management details. If you really need it, let me know. Also you can read the encryption section of 802.11 With the spinoff of the Enterprise portion of Lucents business, will the 128-bit variant quietly die? I hope not (assuming that it's any good, of course). Certainly not. But as someone else mentioned, there are U.S. laws or regulations restricting sales of 128-bit encryption overseas. So I kind of doubt it will be enabled on the base stations in Adelaide. But I suppose you can purchase such cards in the U.S. and they will work fine in Adelaide with encryption turned off. As for pricing, note that the price for the cards that will be sold in Adelaide are in Australian dollars which are valued quite differently than U.S. dollars. Disclaimer: I am neither a lawyer or a crypto expert. Nor do I work in the Wavelan division of Lucent. I'm just lamely trying to help.
Re: Suggestion for Automated Security Information
Sir, I thank your for your comments, and agree that perhaps this was not the correct forum, however give the vast reach of the people monitoring this list, the variety of responses, and opinion would have been usefull. Unfortunatly, either I mis-explained myself, or you mis-understood. The purpose of CRAAB is to enable automation of tools to discover vulnerabilities. At present CERT does an excellent job of keeping the security world posted, however it is unreasonable for Miss Jane Bloggs, sat at home on her windows 98 pentium III 500, to know aboult, let alone moniter CERT. Disregard for EVERYONE is the commonality that has thus far allowed remote penetratrion of machines through such mechanisms as VERY WELL KNOWN RPC VULNERABILITIES, which have further permitted the recent DDoS attacks. Your candid disregard for this simple fact may explain how eager you were to disregard my suggestion without quandry. In addition to 'la fammile Bloggs' the fact that CERT caters mainly for OS's ( although admittedly not exclusivley ) however there are many products installed in corporate environments, ISP environments and the home user environment that can, and do, cause vulnerabilities in the security of that system. Many of these products never make it to CERT. Maintaining levels of code on systems ( such as keeping up to date with Sendmail or Kerberos ) are vital tasks, which may have a delay of a few days from being released to Mr Sys Admin discovering this fact. Utilising the suggestion of CRAAB, this information can be automatically discovered by ANYONE with an interest in product X, spanning the whole sphere of what a user has on their machine, not just the OS. Further, it could be extended to download the fixes identified, even install them. Somehow, that doesn't sound like a step in the right direction, but maybe that's merely because third party patch serving schemes have had such interesting histories. Agreed, this is where deeper consideration is required. Steps such as this have allready been made, like Flash upgrading the OS of your cable receiver over the cable feed for example. Installation is an option that need not be considered, however an option it is. ... Monitoring your emails because you subscribed to 70 different bug-traq esque lists is OK, but an automated alerting system ( as this could easily become ) would be less infallible ... If you watch 70 different bug-track lists, then you must like hearing a lot of noise and nonsense. Most reports of security problems from most sources are rumors of misunderstood problems or worse. Even CERT is not immune to the Chicken Little Syndrom. Please accept my appologies for attempting mild humor, or slight sarchasm. however these were bug traq ESQUE and not BUG TRAQ - per se. An attempt to illustrate that if you install an OS, and 15 different applications for example then it is clearly possible that you could b monitoring approx 20 lists, an OS bugs/fixes list, CERT / SANS / X-Force / AUSCERT etc, plus each product mailing list looking for developments and incrimental corrections. Just think how many web sites you visit in 1 day ( disregarding Playboy ) just to keep up on development ( in terms of codefixes ) for your system. Remember that the view of security does not just include the "OH damn XYZ has been broken into" and given that the vendors the Chicken Little Syndrome can be avoided - ie only verified occurences get entered, this is the realm of process however. As said vendors would supply the data so, as opposed to sifting through CERT Advisories for the Vulnerable Systems section to see if this one applies to your OS, you can focus immediatley on ONLY those products / systems you have. your CRAAB agent could run twice daily, examine CRAAB and then report any findings directly to you. This cuts across many fields such as Databases, Cryptography, Systems Integration / Impplimentation and others. Anyway, I thank you for your comments and welcome anyone to send their comments directly do me if they fear that this conversation may pollute the waters that are these mailing lists I also appologise if my candid, pseudo sarchastic method of penning ( typing ) offends you - just making light of the corespondance...Thanks Garreth J... Vernon Schryver wrote: From: Grreth Jeremiah [EMAIL PROTECTED] ... Given any heterogeneous environment, platform or network, an administrator/security professional often needs to keep track of multiple OS bug lists. ... My suggestion is to create an Internet Database where vendors / Emergency Response Teams, may put information in a SPECIFIC format regarding security alerts etc. ... How is this problem related to the work of the IETF? Isn't the IETF supposed to be about protocols? How would this suggestion differ from CERT, besides trivia such as who sponsors the announcements and pays for the
