From payalsin at usc.edu Thu Apr 1 00:32:36 2004 From: payalsin at usc.edu (payal singh) Date: Thu Apr 1 00:33:14 2004 Subject: [Csci551-talk] finals Message-ID: <65403664f713.64f713654036@usc.edu> hi.. does anyone know when the finals are....if its given on the website i cant find it..:)... thanks.. payal From johnh at ISI.EDU Thu Apr 1 10:28:54 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 1 10:29:03 2004 Subject: [Csci551-talk] finals In-Reply-To: <65403664f713.64f713654036@usc.edu> Message-ID: <200404011828.i31ISstn032525@dash.isi.edu> On Thu, 01 Apr 2004 00:32:36 PST, payal singh wrote: >hi.. > >does anyone know when the finals are....if its given on the website i cant >find it..:)... > >thanks.. > >payal Most of the schedule information on the syllabus. -John Heidemann From atu011 at earthlink.net Sat Apr 3 15:45:06 2004 From: atu011 at earthlink.net (Aaron Tu) Date: Sat Apr 3 15:45:21 2004 Subject: [Csci551-talk] Java Compiler in Aludra In-Reply-To: <200403302000.i2UK09k20210@gamma.isi.edu> Message-ID: <000001c419d5$b154a720$6701a8c0@LATUALP> Is there a java compiler in aludra? Aaron From naa at usc.edu Sat Apr 3 17:03:20 2004 From: naa at usc.edu (nishant agarwal) Date: Sat Apr 3 17:03:26 2004 Subject: [Csci551-talk] Java Compiler in Aludra Message-ID: you should do this sourcing to get running: source /usr/usc/jdk/default/setup.csh you should be fine after that. If you want to use .NET , you can do so via a portal to a Windows 2000 machine, only about 100 nodes are available on an experimental basis. The virtual machine is available on synergy.usc.edu Nishant ----- Original Message ----- From: Aaron Tu Date: Saturday, April 3, 2004 3:45 pm Subject: [Csci551-talk] Java Compiler in Aludra > Is there a java compiler in aludra? > > Aaron > > From atu011 at earthlink.net Sat Apr 3 21:06:14 2004 From: atu011 at earthlink.net (Aaron Tu) Date: Sat Apr 3 21:06:29 2004 Subject: [Csci551-talk] Java Compiler in Aludra In-Reply-To: Message-ID: <000101c41a02$8e4f3970$6701a8c0@LATUALP> I tried your suggestion but permission was denied? Aaron -----Original Message----- From: nishant agarwal [mailto:naa@usc.edu] Sent: Saturday, April 03, 2004 5:03 PM To: Aaron Tu Cc: csci551-talk@mailman.isi.edu Subject: Re: [Csci551-talk] Java Compiler in Aludra you should do this sourcing to get running: source /usr/usc/jdk/default/setup.csh you should be fine after that. If you want to use .NET , you can do so via a portal to a Windows 2000 machine, only about 100 nodes are available on an experimental basis. The virtual machine is available on synergy.usc.edu Nishant ----- Original Message ----- From: Aaron Tu Date: Saturday, April 3, 2004 3:45 pm Subject: [Csci551-talk] Java Compiler in Aludra > Is there a java compiler in aludra? > > Aaron > > From naa at usc.edu Sat Apr 3 21:57:02 2004 From: naa at usc.edu (nishant agarwal) Date: Sat Apr 3 21:57:05 2004 Subject: [Csci551-talk] Java Compiler in Aludra Message-ID: Just type this as a command. it will definitely work. type the line on the shell prompt and hit enter. ----- Original Message ----- From: Aaron Tu Date: Saturday, April 3, 2004 9:06 pm Subject: RE: [Csci551-talk] Java Compiler in Aludra > I tried your suggestion but permission was denied? > > Aaron > > -----Original Message----- > From: nishant agarwal [naa@usc.edu] > Sent: Saturday, April 03, 2004 5:03 PM > To: Aaron Tu > Cc: csci551-talk@mailman.isi.edu > Subject: Re: [Csci551-talk] Java Compiler in Aludra > > you should do this sourcing to get running: > source /usr/usc/jdk/default/setup.csh > > you should be fine after that. If you want to use .NET , you can do so > via a > portal to a Windows 2000 machine, only about 100 nodes are available on > an > experimental basis. The virtual machine is available on synergy.usc.edu > > Nishant > > ----- Original Message ----- > From: Aaron Tu > Date: Saturday, April 3, 2004 3:45 pm > Subject: [Csci551-talk] Java Compiler in Aludra > > > Is there a java compiler in aludra? > > > > Aaron > > > > > > From gvagarwa at usc.edu Sun Apr 4 16:55:43 2004 From: gvagarwa at usc.edu (gaurav agarwal) Date: Sun Apr 4 16:56:02 2004 Subject: [Csci551-talk] midterm key Message-ID: HI, Is a midterm key going to be posted? Thanks, Gaurav From johnh at ISI.EDU Sun Apr 4 19:42:34 2004 From: johnh at ISI.EDU (John Heidemann) Date: Sun Apr 4 19:43:01 2004 Subject: [Csci551-talk] midterm key In-Reply-To: Message-ID: <200404050242.i352gYN5018091@dash.isi.edu> On Sun, 04 Apr 2004 16:55:43 PDT, gaurav agarwal wrote: >HI, >Is a midterm key going to be posted? > >Thanks, >Gaurav No. Although I spent the beginning of last class talking about some questions. I do however strongly encourage students with questions to talk to me or the TA in office hours. -John Heidemann From atu011 at earthlink.net Mon Apr 5 22:31:59 2004 From: atu011 at earthlink.net (Aaron Tu) Date: Mon Apr 5 22:32:06 2004 Subject: [Csci551-talk] IEEE Journals In-Reply-To: <200404051900.i35J0Dk28026@gamma.isi.edu> Message-ID: <000401c41b98$7c2f9a90$7a503e9f@LATUALP> Does anyone know if we have any access to IEEE journals? Any student discount rate? Aaron From johnh at ISI.EDU Tue Apr 6 10:41:33 2004 From: johnh at ISI.EDU (John Heidemann) Date: Tue Apr 6 10:41:54 2004 Subject: [Csci551-talk] IEEE Journals In-Reply-To: <000401c41b98$7c2f9a90$7a503e9f@LATUALP> Message-ID: <200404061741.i36HfXGN029973@dash.isi.edu> On Mon, 05 Apr 2004 22:31:59 PDT, "Aaron Tu" wrote: >Does anyone know if we have any access to IEEE journals? Any student >discount rate? > >Aaron I believe USC has an on-line subscription (provided you browse form a USC IP address). -John Heidemann From pilani at usc.edu Tue Apr 6 12:29:07 2004 From: pilani at usc.edu (rahul pilani) Date: Tue Apr 6 12:29:13 2004 Subject: [Csci551-talk] Winsock Implementation Message-ID: <3e4f203e84bc.3e84bc3e4f20@usc.edu> The other day in class, the professor was talking bout how Solaris messed up some of the Socket Implementation. I was wondering how good is the Windows Socket implementation and whether it tries to make its own "optimizations". Rahul From coolrocks at tom.com Tue Apr 6 17:54:19 2004 From: coolrocks at tom.com (Coolrocks) Date: Tue Apr 6 17:54:29 2004 Subject: [Csci551-talk] HW3 Q2.b) Message-ID: <00d601c41c3a$dde834c0$6500a8c0@coolrocks> Hi, In question 2 b). It mentioned that there is a startup latency in DSR. Can someone tell me what is the startup latency in DSR? How would the change to "fixed" nodes affect the startup process in DSR? thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://gamma.isi.edu/pipermail/csci551-talk/attachments/20040406/49f56b64/attachment.html From atu011 at earthlink.net Thu Apr 8 01:00:15 2004 From: atu011 at earthlink.net (Aaron Tu) Date: Thu Apr 8 01:00:24 2004 Subject: [Csci551-talk] Backspace & Delete Bug with Cygwin SSH In-Reply-To: <200404071900.i37J06k00814@gamma.isi.edu> Message-ID: <000001c41d3f$873e51d0$6701a8c0@LATUALP> I used cygwin ssh to login to aludra account. For some reason the backspace and the delete keys don't work. Does anyone know what's going on? Also does any know how to reconfig aludra account to use tcsh or bash instead of the default csh? Thank you. Aaron From atu011 at earthlink.net Thu Apr 8 01:08:40 2004 From: atu011 at earthlink.net (Aaron Tu) Date: Thu Apr 8 01:08:46 2004 Subject: [Csci551-talk] Using Visual Studio IDE for Cygwin gcc In-Reply-To: <200404071900.i37J06k00814@gamma.isi.edu> Message-ID: <000101c41d40$b3d09400$6701a8c0@LATUALP> Has anyone successfully integrated Visual Studio IDE to interface with Cygwin gcc? I would love to find out how to integrate the error output generate by gcc with Visual Studio IDE. Aaron From johnh at ISI.EDU Thu Apr 8 14:40:45 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 8 19:04:27 2004 Subject: [Csci551-talk] Using Visual Studio IDE for Cygwin gcc In-Reply-To: <000101c41d40$b3d09400$6701a8c0@LATUALP> Message-ID: <200404082140.i38LejrM030662@dash.isi.edu> On Thu, 08 Apr 2004 01:08:40 PDT, "Aaron Tu" wrote: >Has anyone successfully integrated Visual Studio IDE to interface with >Cygwin gcc? I would love to find out how to integrate the error output >generate by gcc with Visual Studio IDE. While not visual studio, you can see compilation mode in emacs. -John Heidemann From johnh at ISI.EDU Thu Apr 8 14:39:29 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 8 19:04:30 2004 Subject: [Csci551-talk] Backspace & Delete Bug with Cygwin SSH In-Reply-To: <000001c41d3f$873e51d0$6701a8c0@LATUALP> Message-ID: <200404082139.i38LdTKm030645@dash.isi.edu> On Thu, 08 Apr 2004 01:00:15 PDT, "Aaron Tu" wrote: >I used cygwin ssh to login to aludra account. For some reason the >backspace and the delete keys don't work. Does anyone know what's going >on? Also does any know how to reconfig aludra account to use tcsh or >bash instead of the default csh? See the man page for stty (search for "erase") and/or check your terminal program. (Presumably ISD would have more detail and/or lab staff that could answer more explicitly.) -John Heidemann From johnh at ISI.EDU Thu Apr 8 14:32:10 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 8 19:04:31 2004 Subject: [Csci551-talk] HW3 Q2.b) In-Reply-To: <00d601c41c3a$dde834c0$6500a8c0@coolrocks> Message-ID: <200404082132.i38LWACC030601@dash.isi.edu> On Tue, 06 Apr 2004 17:54:19 PDT, "Coolrocks" wrote: >Hi, > In question 2 b). It mentioned that there is a startup latency in DSR. Can >someone tell me what is the startup latency in DSR? How would the change to >"fixed" nodes affect the startup process in DSR? > >thanks! > > This question sounds a lot like "please answer question 2b for me". (Perhaps why you're using an anonymous mailbox?) If you don't understand DSR you should review the paper and the lecture, and, if necessary, come in to the TA or my office hours to discuss it. -John Heidemann From johnh at ISI.EDU Thu Apr 8 14:27:20 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 8 19:04:33 2004 Subject: [Csci551-talk] Winsock Implementation In-Reply-To: <3e4f203e84bc.3e84bc3e4f20@usc.edu> Message-ID: <200404082127.i38LRKFf030576@dash.isi.edu> On Tue, 06 Apr 2004 12:29:07 PDT, rahul pilani wrote: > >The other day in class, the professor was talking bout how Solaris messed up >some of the Socket Implementation. I was wondering how good is the Windows >Socket implementation and whether it tries to make its own "optimizations". > >Rahul Good question for class. I'm not completely sure (I haven't seen a detailed comparison). First, there are a number of different MS stacks in different versions of Windows. (Just like there are a number of versions of BSD and Linux, each with slight TCP variations.) My general understanding is that recent Windows versions (Windows 2000 and later?) follow all the important core algorithms (AIMD, fast retransmit, fast recovery) reasonably well. I believe the most recent versions also claim to do SACK, although I don't know how well. (Implementing a good SACK is supposed to be non-trivial, given the combinations of what to send and how much and when.) For interested students, there should be web pages documenting this. I believe Matt Mathis at the Pittsburgh Supercomputer Center maintains a page about TCP configs for high performance that would describe this in more detail. Wrt TCP at least, Microsoft seems to be doing a reasonable job of following standards. (By comparison, their use of Kerberos in NT requires propritary, non-documented extensions for full functionality.) I believe there are third party (non-Microsoft) "TCP accellerators" for Windows, some of which change TCP out of spec. Such things would be Bad. -John Heidemann From johnh at ISI.EDU Sun Apr 11 20:47:45 2004 From: johnh at ISI.EDU (John Heidemann) Date: Sun Apr 11 20:50:07 2004 Subject: [Csci551-talk] project b on web site Message-ID: <200404120347.i3C3ljje017680@dash.isi.edu> CSci551 Project B is now posted to the web site. Yuan Li will post sample code for Project A by tomorrow. You may choose to use it if you want, or to use your own Project A code to do Project B. -John Heidemann From gvagarwa at usc.edu Sun Apr 11 21:17:21 2004 From: gvagarwa at usc.edu (gaurav agarwal) Date: Sun Apr 11 21:19:58 2004 Subject: [Csci551-talk] project b on web site Message-ID: <5ba6435c13e5.5c13e55ba643@usc.edu> Hi Professor Will the grades for Project A be posted soon? We need it to know if our implementation was correct and robust, so that we can use it for Project B. Thanks, Gaurav ----- Original Message ----- From: John Heidemann Date: Sunday, April 11, 2004 8:47 pm Subject: [Csci551-talk] project b on web site > > CSci551 Project B is now posted to the web site. > > Yuan Li will post sample code for Project A by tomorrow. > You may choose to use it if you want, or to use your own Project A > code to do Project B. > > -John Heidemann > From liyuan at pollux.usc.edu Sun Apr 11 22:11:21 2004 From: liyuan at pollux.usc.edu (Yuan Li) Date: Sun Apr 11 22:13:59 2004 Subject: [Csci551-talk] Sample code for project A Message-ID: Sample code for project A is posted, please check. Thanks Yuan From salpekar at usc.edu Wed Apr 14 21:24:34 2004 From: salpekar at usc.edu (ajay salpekar) Date: Wed Apr 14 21:26:40 2004 Subject: [Csci551-talk] external routes, parsing on the fly Message-ID: <7c2877af71d7.407dac12@usc.edu> Project B doubts... 1) Am not clear about external routes - "we will not use external routes (although relevant parts of the configuration file will still be there" Does this mean that the cfg may or may not contain external routes, and in any case we just summarily disregard them? We'd simply skip the external routes config section in the file, that occurs before its 0.0.0.0 ? 2) I initially thought (2. Network Stability and Packet Routing) I'd parse in the "r 1 10.1.0.1 10.1.0.2" lookup lines from the cfg file right at the beginning and store in a to-do list of sorts, and thenn fork all the routers and then pass them their respective to-do commands. The problem I found with this was - in 3. Adding Traffic to Your Network, it seems we'd need to read the "s sumthng sumthng" and "w sumthng sumthng" on the fly - it also says "Your manager will need to read each line, inform the relevant router...." My question is, can I use the preload method for Stage5, and then do this on- the-fly parsing for Stage6? (it's mentioned somewhere that "the manager should continue processing the input file.", which is why I ask if preloading from the cfg file is ok) From salpekar at usc.edu Wed Apr 14 21:37:44 2004 From: salpekar at usc.edu (ajay salpekar) Date: Wed Apr 14 21:38:45 2004 Subject: [Csci551-talk] prefix checking, data packet format Message-ID: <913ddcee1c67.407daf28@usc.edu> 1) It's unclear to me what's meant by "You WILL need to consider prefixes, though"Does this simply mean that we'd need to hunt for a match for the destn IP in the concerned router's table and just put out a distance for it, or does it mean that we can have config input lines like the following : r 1 10.1.0.1 10.1.0.2 r 1 11.X.X.X 10.1.0.3 router 1's own IP here is 10.1.0.0. So does "consider prefixes" mean that I will need to check if the source IP is definitely within the subnet address range represented by the router 1? Or will such inputs never occur? 2) It seems that we'd need to add a few fields to the LSA packet if we're going to use it to shunt data between routers - origin source ip (h1) and destn source ip (h2), plus whatever else might come up later on. We use the same length for marshalling the IP fields as we used for the Project A IP fields do we? And if I need to pass other fields in addition (supposing I need to), is it up to me to decide their field lengths? From salpekar at usc.edu Wed Apr 14 21:46:57 2004 From: salpekar at usc.edu (ajay salpekar) Date: Wed Apr 14 21:48:39 2004 Subject: [Csci551-talk] waiting for stability, non-zero loss probability Message-ID: <9f09dc5f2840.407db151@usc.edu> 1) "w 0 0.0.0.0 0.0.0.0" would cause say a 3 second sleep() in my program execution to give time for routes to stabilize. But it's also mentioned that if we get several "s sumthng sumthng" lines in a row, we cant choose to put in say a tiny sleep() for packet travel-time. So my question is, how is this different from a "w sumthng sumthng" line? If we're allowed to make routers pause between a few consecutive "s sumthgn sumthgn" lines, why is the "w" line specification included? I'm thinking maybe I've got something very very wrong somewhere in my reasoning or interpretation.. could you please clarify? 2) The last line for 3. talks about not counting dropped packets as received ones. But in 1. Overview it says "You may assume that the loss rate will always be zero for all stages of this project" What do I interpret from these two references? Thank you Sir. From johnh at ISI.EDU Thu Apr 15 09:52:39 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 15 09:55:13 2004 Subject: [Csci551-talk] project b on web site In-Reply-To: <5ba6435c13e5.5c13e55ba643@usc.edu> Message-ID: <200404151652.i3FGqdlb016099@dash.isi.edu> On Sun, 11 Apr 2004 21:17:21 PDT, gaurav agarwal wrote: >Will the grades for Project A be posted soon? We need it to know if our >implementation was correct and robust, so that we can use it for Project B. I hope that Proj A grades will be out soon; Yuan can comment when. However, you should be able to get an idea if your Project A is solid by testing it! -John Heidemann > >Thanks, >Gaurav > >----- Original Message ----- >From: John Heidemann >Date: Sunday, April 11, 2004 8:47 pm >Subject: [Csci551-talk] project b on web site > >> >> CSci551 Project B is now posted to the web site. >> >> Yuan Li will post sample code for Project A by tomorrow. >> You may choose to use it if you want, or to use your own Project A >> code to do Project B. >> >> -John Heidemann >> From johnh at ISI.EDU Thu Apr 15 09:57:00 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 15 09:58:46 2004 Subject: [Csci551-talk] external routes, parsing on the fly In-Reply-To: <7c2877af71d7.407dac12@usc.edu> Message-ID: <200404151657.i3FGv0fU016141@dash.isi.edu> On Wed, 14 Apr 2004 21:24:34 PDT, ajay salpekar wrote: >Project B doubts... > > >1) Am not clear about external routes - "we will not use external routes >(although relevant parts of the configuration file will still be there" > >Does this mean that the cfg may or may not contain external routes, and in any >case we just summarily disregard them? We'd simply skip the external routes >config section in the file, that occurs before its 0.0.0.0 ? There is a sample config file in the project be handout. > > > >2) I initially thought (2. Network Stability and Packet Routing) I'd parse in >the "r 1 10.1.0.1 10.1.0.2" lookup lines from the cfg file right at the >beginning and store in a to-do list of sorts, and thenn fork all the routers >and then pass them their respective to-do commands. > >The problem I found with this was - in 3. Adding Traffic to Your Network, it >seems we'd need to read the "s sumthng sumthng" and "w sumthng sumthng" on the >fly - it also says "Your manager will need to read each line, inform the >relevant router...." > >My question is, can I use the preload method for Stage5, and then do this on- >the-fly parsing for Stage6? (it's mentioned somewhere that "the manager should >continue processing the input file.", which is why I ask if preloading from >the cfg file is ok) > If you can reconcile the "w" command (that requires routing stablize) with pre-sending the commands, it doesn't matter when you actually send them. But my guess is the easist thing to do is have the manager coordinate detecting stability and sending things out. -John Heidemann From johnh at ISI.EDU Thu Apr 15 10:54:39 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 15 10:56:50 2004 Subject: [Csci551-talk] prefix checking, data packet format In-Reply-To: <913ddcee1c67.407daf28@usc.edu> Message-ID: <200404151754.i3FHsdW0016658@dash.isi.edu> On Wed, 14 Apr 2004 21:37:44 PDT, ajay salpekar wrote: >1) It's unclear to me what's meant by "You WILL need to consider prefixes, >though"Does this simply mean that we'd need to hunt for a match for the destn >IP in the concerned router's table and just put out a distance for it, or does >it mean that we can have config input lines like the following : > >r 1 10.1.0.1 10.1.0.2 >r 1 11.X.X.X 10.1.0.3 > >router 1's own IP here is 10.1.0.0. So does "consider prefixes" mean that I >will need to check if the source IP is definitely within the subnet address >range represented by the router 1? Or will such inputs never occur? Actually, router's in the assignment don't have IP addresses, they just manage ranges of IP address space. About existence, the project says: You may assume that all router-ids and src-IP-addresses will exist in your system. It's possible that destination-IP-address will or might not exist in your system. The originating router should discard packets that aren't routable. >2) It seems that we'd need to add a few fields to the LSA packet if we're >going to use it to shunt data between routers - origin source ip (h1) and >destn source ip (h2), plus whatever else might come up later on. We use the >same length for marshalling the IP fields as we used for the Project A IP >fields do we? And if I need to pass other fields in addition (supposing I need >to), is it up to me to decide their field lengths? As with both projects, if you need to change the message format, please note that in your readme. (I agree to send data messages you'll need to at least add a new type code.) -John Heidemann From johnh at ISI.EDU Thu Apr 15 10:57:26 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 15 10:58:43 2004 Subject: [Csci551-talk] waiting for stability, non-zero loss probability In-Reply-To: <9f09dc5f2840.407db151@usc.edu> Message-ID: <200404151757.i3FHvQfc016678@dash.isi.edu> On Wed, 14 Apr 2004 21:46:57 PDT, ajay salpekar wrote: >1) "w 0 0.0.0.0 0.0.0.0" would cause say a 3 second sleep() in my program >execution to give time for routes to stabilize. But it's also mentioned that >if we get several "s sumthng sumthng" lines in a row, we cant choose to put in >say a tiny sleep() for packet travel-time. So my question is, how is this >different from a "w sumthng sumthng" line? If we're allowed to make routers >pause between a few consecutive "s sumthgn sumthgn" lines, why is the "w" line >specification included? > >I'm thinking maybe I've got something very very wrong somewhere in my >reasoning or interpretation.. could you please clarify? Presumably packets might require a different amount of time to travel than routing does to converge. > > >2) The last line for 3. talks about not counting dropped packets as received >ones. But in 1. Overview it says "You may assume that the loss rate will >always be zero for all stages of this project" > >What do I interpret from these two references? They're not actually in conflict, although the second that you list perhaps makes the first not very relevant :-) -John Heidemann From liyuan at pollux.usc.edu Thu Apr 15 11:26:53 2004 From: liyuan at pollux.usc.edu (Yuan Li) Date: Thu Apr 15 11:29:26 2004 Subject: [Csci551-talk] project b on web site In-Reply-To: <5ba6435c13e5.5c13e55ba643@usc.edu> Message-ID: You will receive the grades for project A soon. Hopefully by the end of this weekend. Thanks Yuan On Sun, 11 Apr 2004, gaurav agarwal wrote: > Hi Professor > > Will the grades for Project A be posted soon? We need it to know if our > implementation was correct and robust, so that we can use it for Project B. > > Thanks, > Gaurav > > ----- Original Message ----- > From: John Heidemann > Date: Sunday, April 11, 2004 8:47 pm > Subject: [Csci551-talk] project b on web site > > > > > CSci551 Project B is now posted to the web site. > > > > Yuan Li will post sample code for Project A by tomorrow. > > You may choose to use it if you want, or to use your own Project A > > code to do Project B. > > > > -John Heidemann > > > From johnh at ISI.EDU Thu Apr 15 15:42:06 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 15 15:45:47 2004 Subject: [Csci551-talk] DoS/security papers Message-ID: <200404152242.i3FMg7Mp018851@dash.isi.edu> Looking at where we are in the semester, I'd like to drop the paper [Kuzmanovic03b] "Low-rate tcp-targeted denial of service attacks"; it's the most specialized of the three DoS papers. Please consider that paper moved to the "supplemental" category. -John Heidemann From gvagarwa at usc.edu Thu Apr 15 20:14:16 2004 From: gvagarwa at usc.edu (gaurav agarwal) Date: Thu Apr 15 20:17:06 2004 Subject: [Csci551-talk] Submit tag for HW3 Message-ID: Hi In the handout it says hw2, is that supposed to be hw3? Thanks, Gaurav From johnh at ISI.EDU Thu Apr 15 22:13:01 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 15 22:14:46 2004 Subject: [Csci551-talk] Re: Submit tag for HW3 In-Reply-To: Message-ID: <200404160513.i3G5D1N5023090@dash.isi.edu> On Thu, 15 Apr 2004 20:14:16 PDT, gaurav agarwal wrote: >Hi > >In the handout it says hw2, is that supposed to be hw3? > >Thanks, >Gaurav Yes. -John Heidemann From devarshi at ieee.org Sat Apr 17 20:56:56 2004 From: devarshi at ieee.org (Devarshi Shah) Date: Sat Apr 17 20:59:22 2004 Subject: [Csci551-talk] Part 4 : regarding sending data packets Message-ID: <1082260616.8007.6.camel@maverick> Hi, I had a question regarding the sending of data packets in part 4. If suppose we have a couple of consecutive sends, and they cause the MED to change, are we supposed to continue sending the remaining data packets without waiting for the routing tables to stabilize following the MED value changes ? Or, are we expected to wait for the routing tables to re-stabilize once the MED values change before we continue sending more data packets ? Thanks, Devarshi From sblackmo at usc.edu Sun Apr 18 20:06:51 2004 From: sblackmo at usc.edu (stephen blackmon) Date: Sun Apr 18 20:09:24 2004 Subject: [Csci551-talk] Sample Project A Message-ID: I have not been able to build the provided project A code on linux or solaris. Some background: the timers API and test-app work fine, but doing a make all or a make of any subproject gives syntax errors, parse errors, and 'ISO C++ forbids' errors in every file. Has anyone done this successfully? If you would suggest edits to the makefile, compiler flags, or a build order that might work, it would be very helpful. mailto:steve@linux.usc.edu Thanks! From liyuan at pollux.usc.edu Sun Apr 18 23:55:00 2004 From: liyuan at pollux.usc.edu (Yuan Li) Date: Sun Apr 18 23:57:17 2004 Subject: [Csci551-talk] Project A grade sent Message-ID: 1. I posted all the testcases used for grading project A on TA's web page. 2. Please run these files first before sending queries about the grades. 3. How to read the grade report? I listed the grade sheet on my web page and you can check the points distribution for each part. 4. Please email me if you still have questions regarding the grade after finishing all mentioned above. 5. Email me at: liyuan@pollux.usc.edu Thanks Yuan From liyuan at pollux.usc.edu Tue Apr 20 08:23:32 2004 From: liyuan at pollux.usc.edu (Yuan Li) Date: Tue Apr 20 08:25:37 2004 Subject: [Csci551-talk] Sample Project A In-Reply-To: Message-ID: It should be able to compile on linux now. One more thing, everybody must test his program on Aludra/nunki! We won't grade projects on Linux. Thanks Yuan On Sun, 18 Apr 2004, stephen blackmon wrote: > I have not been able to build the provided project A code on linux or solaris. Some background: the timers API and test-app work fine, but doing a make all or a make of any subproject gives syntax errors, parse errors, and 'ISO C++ forbids' errors in every file. Has anyone done this successfully? If you would suggest edits to the makefile, compiler flags, or a build order that might work, it would be very helpful. > > mailto:steve@linux.usc.edu > > Thanks! > From pilani at usc.edu Wed Apr 21 01:21:41 2004 From: pilani at usc.edu (Rahul Pilani) Date: Wed Apr 21 01:22:16 2004 Subject: [Csci551-talk] strange article.. Message-ID: <40862F15.40201@usc.edu> This is an article from WIRED Magazine regarding a security flaw on the internet. I have edited it a little to remove the unnecessary parts. The whole article can be read at : http://www.wired.com/news/technology/0,1282,63143,00.html?tw=wn_tophead_2 I had some questions regarding the article.. here it is: >>Researchers found a serious security flaw that left core Internet technology vulnerable to hackers. >>Experts said the flaw, disclosed Tuesday by the British government, affects the underlying technology for nearly all Internet traffic. >>Left unaddressed, they said, it could allow hackers to knock computers offline and broadly disrupt vital traffic-directing devices, called routers, >>that coordinate the flow of data among distant groups of computers. >> >>The flaw affecting TCP, was discovered late last year by a computer researcher in Milwaukee, Paul "Tony" Watson, 36, >>who said he identified a method to reliably trick personal computers and routers into shutting down electronic conversations by resetting the machines remotely. >> Is it similar to age-old hacking techniques like buffer-overflow etc?.. >>Routers continually exchange important updates about the most efficient traffic routes between large networks. How is exchanging routes concerned with TCP ? I think what the so called "Technical Writer" is referring to some routing protocol like BGP.. >>Continued successful attacks against routers can cause them to go into a stand-by mode, known as "dampening," that can persist for hours. What is the dampening mode that is being talked about?.. Is it OS specific or is part of any protocol? >> >>Experts previously maintained such attacks could take between four to 142 years to succeed because they require guessing a rotating number from >>roughly 4 billion possible combinations. Watson said he can guess the proper number with as few as four attempts, which can be accomplished within seconds. Combinations of what?.. Does anybody have anymore details of what this article is all about?? or is it just paranoia?.. Regards, Rahul Pilani From wakerly at usc.edu Wed Apr 21 01:44:49 2004 From: wakerly at usc.edu (mike wakerly) Date: Wed Apr 21 01:48:17 2004 Subject: [Csci551-talk] strange article.. In-Reply-To: <40862F15.40201@usc.edu> References: <40862F15.40201@usc.edu> Message-ID: <268B8748-9370-11D8-8E13-000A95A6AAA6@usc.edu> On Apr 21, 2004, at 1:21 AM, Rahul Pilani wrote: > Is it similar to age-old hacking techniques like buffer-overflow etc?.. No, the flaw is not nearly as general. It seems that many TCP stacks incorrectly handle RST commands in a TCP connection, and as a consequence, could be tricked into closing a connection. It is important to realize that this seems to be an implementation flaw -- TCP doesn't need to be changed, but some stacks may. > >>Routers continually exchange important updates about the most > efficient traffic routes between large networks. > > How is exchanging routes concerned with TCP ? > I think what the so called "Technical Writer" is referring to some > routing protocol like BGP.. Right, I think something I read earlier today about this mentioned BGP explicitly. Whatever that article was, it suggested BGP connections could be targeted because (1) they are generally left open (eg, long-lived), and (2) resetting and hence killing such a connection could cause wider-spread disconnection -- at least until, say, withdrawn routes are re-advertised. > >>Continued successful attacks against routers can cause them to go > into a stand-by mode, known as "dampening," that can persist for > hours. > > What is the dampening mode that is being talked about?.. Is it OS > specific or is part of any protocol? No idea :) > >>Experts previously maintained such attacks could take between four > to 142 years to succeed because they require guessing a rotating > number from > >>roughly 4 billion possible combinations. Watson said he can guess > the proper number with as few as four attempts, which can be > accomplished within seconds. > > Combinations of what?.. > Does anybody have anymore details of what this article is all about?? > or is it just paranoia?.. To simplify, injecting a packet into a TCP flow is hard because predicting the sequence number is hard. The flaw here is that someone observed a TCP implementation that accepts RST packets with not only the next sequence number, but any sequence number within a certain window. By reducing the space of acceptable sequence numbers, the difficulty in injecting a packet is reduced. I'd say this is mostly paranoia. It's an easy problem to fix, and in the meantime, not likely to be terribly widespread. Cheers, Mike From wakerly at usc.edu Wed Apr 21 01:52:14 2004 From: wakerly at usc.edu (mike wakerly) Date: Wed Apr 21 01:52:16 2004 Subject: [Csci551-talk] strange article.. In-Reply-To: <40862F15.40201@usc.edu> References: <40862F15.40201@usc.edu> Message-ID: <2F4D95AE-9371-11D8-8E13-000A95A6AAA6@usc.edu> On Apr 21, 2004, at 1:21 AM, Rahul Pilani wrote: > Watson said he can guess the proper number with as few as four > attempts, which can be accomplished within seconds. PS: From this admission, you can guess that he found a TCP implementation that accepts any sequence number within an 8-bit window. (First guess is in [0,2**8)], next in [2**8,2**16), and so on..) Cheers, Mike From rshroff at usc.edu Wed Apr 21 02:13:58 2004 From: rshroff at usc.edu (rajesh shroff) Date: Wed Apr 21 02:16:30 2004 Subject: [Csci551-talk] strange article.. Message-ID: <9ed98f012400.4085d8e6@usc.edu> Dampening is a feature introduced for the routing protocols to consider a router down and not available for routing of packets till that router is stable (no flapping). Browsing further through the CISCO IOS SOFTWARE RELEASES Link: http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bc8.html#wp1024977 This para is imp: The IP Event Dampening feature introduces a configurable exponential decay mechanism to suppress the effects of excessive interface flapping events on routing protocols and routing tables in the network. This feature allows the network operator to configure a router to automatically identify and selectively dampen a local interface that is flapping. Dampening an interface removes the interface from the network until the interface stops flapping and becomes stable. Configuring the IP Event Dampening feature improves convergence times and stability throughout the network by isolating failures so that disturbances are not propagated, which reduces the utilization of system processing resources by other devices in the network and improves overall network stability. After reading through this it also now makes sense with the statement in the article as : """> > >>Continued successful attacks against routers can cause them to go > > into a stand-by mode, known as "dampening," that can persist for > > hours.""" So now as Mike said killing such an active BGP connection would cause wider-spread disconnection -- at least until, say, withdrawn routes are re-advertised. And as per this feature of dampening, this perticular router will not be available to the network for routing purposes and hence will disrupt the normal routing procedure. does this not make more sense now..... ----- Original Message ----- From: mike wakerly Date: Wednesday, April 21, 2004 1:44 am Subject: Re: [Csci551-talk] strange article.. > On Apr 21, 2004, at 1:21 AM, Rahul Pilani wrote: > > Is it similar to age-old hacking techniques like buffer-overflow etc?.. > > No, the flaw is not nearly as general. It seems that many TCP stacks > incorrectly handle RST commands in a TCP connection, and as a > consequence, could be tricked into closing a connection. It is > important to realize that this seems to be an implementation flaw -- > TCP doesn't need to be changed, but some stacks may. > > > >>Routers continually exchange important updates about the most > > efficient traffic routes between large networks. > > > > How is exchanging routes concerned with TCP ? > > I think what the so called "Technical Writer" is referring to some > > routing protocol like BGP.. > > Right, I think something I read earlier today about this mentioned BGP > explicitly. Whatever that article was, it suggested BGP connections > could be targeted because (1) they are generally left open (eg, > long-lived), and (2) resetting and hence killing such a connection > could cause wider-spread disconnection -- at least until, say, > withdrawn routes are re-advertised. > > > >>Continued successful attacks against routers can cause them to go > > into a stand-by mode, known as "dampening," that can persist for > > hours. > > > > What is the dampening mode that is being talked about?.. Is it OS > > specific or is part of any protocol? > > No idea :) > > > >>Experts previously maintained such attacks could take between four > > to 142 years to succeed because they require guessing a rotating > > number from > > >>roughly 4 billion possible combinations. Watson said he can guess > > the proper number with as few as four attempts, which can be > > accomplished within seconds. > > > > Combinations of what?.. > > Does anybody have anymore details of what this article is all about?? > > or is it just paranoia?.. > > To simplify, injecting a packet into a TCP flow is hard because > predicting the sequence number is hard. The flaw here is that someone > observed a TCP implementation that accepts RST packets with not only > the next sequence number, but any sequence number within a certain > window. By reducing the space of acceptable sequence numbers, the > difficulty in injecting a packet is reduced. > > I'd say this is mostly paranoia. It's an easy problem to fix, and in > the meantime, not likely to be terribly widespread. > > Cheers, > Mike > > From bshukla at usc.edu Wed Apr 21 14:48:20 2004 From: bshukla at usc.edu (bhavin shukla) Date: Wed Apr 21 14:52:44 2004 Subject: [Csci551-talk] The new security issue Message-ID: <173f40dc6b51.408689b4@usc.edu> Well Rahul I think this shud clear up some confusion for you: The TPC manages the flow of data packets across the internet. It includes a design feature that allows a TCP communications session to be reset remotely across a network. Sending a reset command depends upon using the correct communications "port", which is set at random by the router beforehand. Previously, the odds of simply guessing this port were thought to be unrealistically high - about one in four billion. NOw Paul Watson, an independent computer security consultant based in the US, discovered that just a portion of the correct number will work. This means a valid reset command could be sent in just a few tries. And repeatedly sending reset commands to carefully chosen routers could prevent network traffic from being forwarded, leaving computers unable to communicate. What is worse is CISCO confirmed that their routers are vunerable :( Also for a closer look of this issue watch out for Watson's presentation on this issue in a paper entitled Slipping In The Window: TCP Reset Attacks at the CanSecWest 2004 conference in Vancouver, Canada, which is going to be held between 21 and 23 April bhavin ----- Original Message ----- From: csci551-talk-request@mailman.isi.edu Date: Wednesday, April 21, 2004 12:00 pm Subject: Csci551-talk Digest, Vol 4, Issue 14 > Send Csci551-talk mailing list submissions to > csci551-talk@mailman.isi.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.isi.edu/mailman/listinfo/csci551-talk > or, via email, send a message with subject or body 'help' to > csci551-talk-request@mailman.isi.edu > > You can reach the person managing the list at > csci551-talk-owner@mailman.isi.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Csci551-talk digest..." > > > Today's Topics: > > 1. strange article.. (Rahul Pilani) > 2. Re: strange article.. (mike wakerly) > 3. Re: strange article.. (mike wakerly) > 4. Re: strange article.. (rajesh shroff) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 21 Apr 2004 01:21:41 -0700 > From: Rahul Pilani > Subject: [Csci551-talk] strange article.. > To: csci551-talk@mailman.isi.edu > Message-ID: <40862F15.40201@usc.edu> > Content-Type: text/plain; charset=us-ascii; format=flowed > > This is an article from WIRED Magazine regarding a security flaw on the > internet. I have edited it a little to remove the unnecessary parts. The > whole article can be read at : > http://www.wired.com/news/technology/0,1282,63143,00.html?tw=wn_tophead_2 > > I had some questions regarding the article.. > here it is: > >>Researchers found a serious security flaw that left core Internet > technology vulnerable to hackers. > >>Experts said the flaw, disclosed Tuesday by the British government, > affects the underlying technology for nearly all Internet traffic. > >>Left unaddressed, they said, it could allow hackers to knock > computers offline and broadly disrupt vital traffic-directing devices, > called routers, > >>that coordinate the flow of data among distant groups of computers. > >> > >>The flaw affecting TCP, was discovered late last year by a computer > researcher in Milwaukee, Paul "Tony" Watson, 36, > >>who said he identified a method to reliably trick personal computers > and routers into shutting down electronic conversations by resetting the > machines remotely. > >> > > Is it similar to age-old hacking techniques like buffer-overflow etc?.. > > >>Routers continually exchange important updates about the most > efficient traffic routes between large networks. > > How is exchanging routes concerned with TCP ? > I think what the so called "Technical Writer" is referring to some > routing protocol like BGP.. > > >>Continued successful attacks against routers can cause them to go > into a stand-by mode, known as "dampening," that can persist for hours. > > What is the dampening mode that is being talked about?.. Is it OS > specific or is part of any protocol? > >> > >>Experts previously maintained such attacks could take between four to > 142 years to succeed because they require guessing a rotating number from > >>roughly 4 billion possible combinations. Watson said he can guess the > proper number with as few as four attempts, which can be accomplished > within seconds. > > Combinations of what?.. > Does anybody have anymore details of what this article is all about?? or > is it just paranoia?.. > > Regards, > Rahul Pilani > > > ------------------------------ > > Message: 2 > Date: Wed, 21 Apr 2004 01:44:49 -0700 > From: mike wakerly > Subject: Re: [Csci551-talk] strange article.. > To: csci551-talk@ISI.EDU > Message-ID: <268B8748-9370-11D8-8E13-000A95A6AAA6@usc.edu> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Apr 21, 2004, at 1:21 AM, Rahul Pilani wrote: > > Is it similar to age-old hacking techniques like buffer-overflow etc?.. > > No, the flaw is not nearly as general. It seems that many TCP stacks > incorrectly handle RST commands in a TCP connection, and as a > consequence, could be tricked into closing a connection. It is > important to realize that this seems to be an implementation flaw -- > TCP doesn't need to be changed, but some stacks may. > > > >>Routers continually exchange important updates about the most > > efficient traffic routes between large networks. > > > > How is exchanging routes concerned with TCP ? > > I think what the so called "Technical Writer" is referring to some > > routing protocol like BGP.. > > Right, I think something I read earlier today about this mentioned BGP > explicitly. Whatever that article was, it suggested BGP connections > could be targeted because (1) they are generally left open (eg, > long-lived), and (2) resetting and hence killing such a connection > could cause wider-spread disconnection -- at least until, say, > withdrawn routes are re-advertised. > > > >>Continued successful attacks against routers can cause them to go > > into a stand-by mode, known as "dampening," that can persist for > > hours. > > > > What is the dampening mode that is being talked about?.. Is it OS > > specific or is part of any protocol? > > No idea :) > > > >>Experts previously maintained such attacks could take between four > > to 142 years to succeed because they require guessing a rotating > > number from > > >>roughly 4 billion possible combinations. Watson said he can guess > > the proper number with as few as four attempts, which can be > > accomplished within seconds. > > > > Combinations of what?.. > > Does anybody have anymore details of what this article is all about?? > > or is it just paranoia?.. > > To simplify, injecting a packet into a TCP flow is hard because > predicting the sequence number is hard. The flaw here is that someone > observed a TCP implementation that accepts RST packets with not only > the next sequence number, but any sequence number within a certain > window. By reducing the space of acceptable sequence numbers, the > difficulty in injecting a packet is reduced. > > I'd say this is mostly paranoia. It's an easy problem to fix, and in > the meantime, not likely to be terribly widespread. > > Cheers, > Mike > > > > ------------------------------ > > Message: 3 > Date: Wed, 21 Apr 2004 01:52:14 -0700 > From: mike wakerly > Subject: Re: [Csci551-talk] strange article.. > To: Rahul Pilani > Cc: csci551-talk@mailman.isi.edu > Message-ID: <2F4D95AE-9371-11D8-8E13-000A95A6AAA6@usc.edu> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Apr 21, 2004, at 1:21 AM, Rahul Pilani wrote: > > Watson said he can guess the proper number with as few as four > > attempts, which can be accomplished within seconds. > > PS: From this admission, you can guess that he found a TCP > implementation that accepts any sequence number within an 8-bit window. > (First guess is in [0,2**8)], next in [2**8,2**16), and so on..) > > Cheers, > Mike > > > > ------------------------------ > > Message: 4 > Date: Wed, 21 Apr 2004 02:13:58 -0700 > From: rajesh shroff > Subject: Re: [Csci551-talk] strange article.. > To: mike wakerly > Cc: csci551-talk@ISI.EDU > Message-ID: <9ed98f012400.4085d8e6@usc.edu> > Content-Type: text/plain; charset=us-ascii > > Dampening is a feature introduced for the routing protocols to consider a > router down and not available for routing of packets till that router is > stable (no flapping). > Browsing further through the CISCO IOS SOFTWARE RELEASES > Link: > http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bc8.html#wp1024977 > This para is imp: > The IP Event Dampening feature introduces a configurable exponential decay > mechanism to suppress the effects of excessive interface flapping events > on routing protocols and routing tables in the network. This feature > allows the network operator to configure a router to automatically > identify and selectively dampen a local interface that is flapping. > Dampening an interface removes the interface from the network until the > interface stops flapping and becomes stable. Configuring the IP Event > Dampening feature improves convergence times and stability throughout the > network by isolating failures so that disturbances are not propagated, > which reduces the utilization of system processing resources by other > devices in the network and improves overall network stability. > > After reading through this it also now makes sense with the statement in > the article as : > > """> > >>Continued successful attacks against routers can cause them to go > > > into a stand-by mode, known as "dampening," that can persist for > > > hours.""" > > So now as Mike said killing such an active BGP connection would cause > wider-spread disconnection -- at least until, say, withdrawn routes are re- > advertised. > And as per this feature of dampening, this perticular router will not be > available to the network for routing purposes and hence will disrupt the > normal routing procedure. > > does this not make more sense now..... > > > ----- Original Message ----- > From: mike wakerly > Date: Wednesday, April 21, 2004 1:44 am > Subject: Re: [Csci551-talk] strange article.. > > > On Apr 21, 2004, at 1:21 AM, Rahul Pilani wrote: > > > Is it similar to age-old hacking techniques like buffer-overflow etc?.. > > > > No, the flaw is not nearly as general. It seems that many TCP stacks > > incorrectly handle RST commands in a TCP connection, and as a > > consequence, could be tricked into closing a connection. It is > > important to realize that this seems to be an implementation flaw -- > > TCP doesn't need to be changed, but some stacks may. > > > > > >>Routers continually exchange important updates about the most > > > efficient traffic routes between large networks. > > > > > > How is exchanging routes concerned with TCP ? > > > I think what the so called "Technical Writer" is referring to some > > > routing protocol like BGP.. > > > > Right, I think something I read earlier today about this mentioned BGP > > explicitly. Whatever that article was, it suggested BGP connections > > could be targeted because (1) they are generally left open (eg, > > long-lived), and (2) resetting and hence killing such a connection > > could cause wider-spread disconnection -- at least until, say, > > withdrawn routes are re-advertised. > > > > > >>Continued successful attacks against routers can cause them to go > > > into a stand-by mode, known as "dampening," that can persist for > > > hours. > > > > > > What is the dampening mode that is being talked about?.. Is it OS > > > specific or is part of any protocol? > > > > No idea :) > > > > > >>Experts previously maintained such attacks could take between four > > > to 142 years to succeed because they require guessing a rotating > > > number from > > > >>roughly 4 billion possible combinations. Watson said he can guess > > > the proper number with as few as four attempts, which can be > > > accomplished within seconds. > > > > > > Combinations of what?.. > > > Does anybody have anymore details of what this article is all about?? > > > or is it just paranoia?.. > > > > To simplify, injecting a packet into a TCP flow is hard because > > predicting the sequence number is hard. The flaw here is that someone > > observed a TCP implementation that accepts RST packets with not only > > the next sequence number, but any sequence number within a certain > > window. By reducing the space of acceptable sequence numbers, the > > difficulty in injecting a packet is reduced. > > > > I'd say this is mostly paranoia. It's an easy problem to fix, and in > > the meantime, not likely to be terribly widespread. > > > > Cheers, > > Mike > > > > > > > > ------------------------------ > > _______________________________________________ > Csci551-talk mailing list > Csci551-talk@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/csci551-talk > > > End of Csci551-talk Digest, Vol 4, Issue 14 > ******************************************* > From bshukla at usc.edu Wed Apr 21 14:57:38 2004 From: bshukla at usc.edu (bhavin shukla) Date: Wed Apr 21 14:58:26 2004 Subject: [Csci551-talk] Re: Csci551-talk Digest, Vol 4, Issue 14 Message-ID: <11eb54f4228.40868be2@usc.edu> oops i forgot to add that 1)this looks like a special case of the TCP Hijacking problem to me where you basically hijack a connection by guessing a port on which you expect TCP communications to be taking place and then just send a RESET to it. 2)And that since BGP uses TCP then is this attack were directed towards a BGP router then BGP routers would also be affected as they rely on persistent connections. 3)Also if you check the advisories then they say that you can get over this problem by using IPSEC(so TCP info will not be seen) OR by not publishing TCP source port info on the web. ----- Original Message ----- From: csci551-talk-request@mailman.isi.edu Date: Wednesday, April 21, 2004 12:00 pm Subject: Csci551-talk Digest, Vol 4, Issue 14 > Send Csci551-talk mailing list submissions to > csci551-talk@mailman.isi.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.isi.edu/mailman/listinfo/csci551-talk > or, via email, send a message with subject or body 'help' to > csci551-talk-request@mailman.isi.edu > > You can reach the person managing the list at > csci551-talk-owner@mailman.isi.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Csci551-talk digest..." > > > Today's Topics: > > 1. strange article.. (Rahul Pilani) > 2. Re: strange article.. (mike wakerly) > 3. Re: strange article.. (mike wakerly) > 4. Re: strange article.. (rajesh shroff) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 21 Apr 2004 01:21:41 -0700 > From: Rahul Pilani > Subject: [Csci551-talk] strange article.. > To: csci551-talk@mailman.isi.edu > Message-ID: <40862F15.40201@usc.edu> > Content-Type: text/plain; charset=us-ascii; format=flowed > > This is an article from WIRED Magazine regarding a security flaw on the > internet. I have edited it a little to remove the unnecessary parts. The > whole article can be read at : > http://www.wired.com/news/technology/0,1282,63143,00.html?tw=wn_tophead_2 > > I had some questions regarding the article.. > here it is: > >>Researchers found a serious security flaw that left core Internet > technology vulnerable to hackers. > >>Experts said the flaw, disclosed Tuesday by the British government, > affects the underlying technology for nearly all Internet traffic. > >>Left unaddressed, they said, it could allow hackers to knock > computers offline and broadly disrupt vital traffic-directing devices, > called routers, > >>that coordinate the flow of data among distant groups of computers. > >> > >>The flaw affecting TCP, was discovered late last year by a computer > researcher in Milwaukee, Paul "Tony" Watson, 36, > >>who said he identified a method to reliably trick personal computers > and routers into shutting down electronic conversations by resetting the > machines remotely. > >> > > Is it similar to age-old hacking techniques like buffer-overflow etc?.. > > >>Routers continually exchange important updates about the most > efficient traffic routes between large networks. > > How is exchanging routes concerned with TCP ? > I think what the so called "Technical Writer" is referring to some > routing protocol like BGP.. > > >>Continued successful attacks against routers can cause them to go > into a stand-by mode, known as "dampening," that can persist for hours. > > What is the dampening mode that is being talked about?.. Is it OS > specific or is part of any protocol? > >> > >>Experts previously maintained such attacks could take between four to > 142 years to succeed because they require guessing a rotating number from > >>roughly 4 billion possible combinations. Watson said he can guess the > proper number with as few as four attempts, which can be accomplished > within seconds. > > Combinations of what?.. > Does anybody have anymore details of what this article is all about?? or > is it just paranoia?.. > > Regards, > Rahul Pilani > > > ------------------------------ > > Message: 2 > Date: Wed, 21 Apr 2004 01:44:49 -0700 > From: mike wakerly > Subject: Re: [Csci551-talk] strange article.. > To: csci551-talk@ISI.EDU > Message-ID: <268B8748-9370-11D8-8E13-000A95A6AAA6@usc.edu> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Apr 21, 2004, at 1:21 AM, Rahul Pilani wrote: > > Is it similar to age-old hacking techniques like buffer-overflow etc?.. > > No, the flaw is not nearly as general. It seems that many TCP stacks > incorrectly handle RST commands in a TCP connection, and as a > consequence, could be tricked into closing a connection. It is > important to realize that this seems to be an implementation flaw -- > TCP doesn't need to be changed, but some stacks may. > > > >>Routers continually exchange important updates about the most > > efficient traffic routes between large networks. > > > > How is exchanging routes concerned with TCP ? > > I think what the so called "Technical Writer" is referring to some > > routing protocol like BGP.. > > Right, I think something I read earlier today about this mentioned BGP > explicitly. Whatever that article was, it suggested BGP connections > could be targeted because (1) they are generally left open (eg, > long-lived), and (2) resetting and hence killing such a connection > could cause wider-spread disconnection -- at least until, say, > withdrawn routes are re-advertised. > > > >>Continued successful attacks against routers can cause them to go > > into a stand-by mode, known as "dampening," that can persist for > > hours. > > > > What is the dampening mode that is being talked about?.. Is it OS > > specific or is part of any protocol? > > No idea :) > > > >>Experts previously maintained such attacks could take between four > > to 142 years to succeed because they require guessing a rotating > > number from > > >>roughly 4 billion possible combinations. Watson said he can guess > > the proper number with as few as four attempts, which can be > > accomplished within seconds. > > > > Combinations of what?.. > > Does anybody have anymore details of what this article is all about?? > > or is it just paranoia?.. > > To simplify, injecting a packet into a TCP flow is hard because > predicting the sequence number is hard. The flaw here is that someone > observed a TCP implementation that accepts RST packets with not only > the next sequence number, but any sequence number within a certain > window. By reducing the space of acceptable sequence numbers, the > difficulty in injecting a packet is reduced. > > I'd say this is mostly paranoia. It's an easy problem to fix, and in > the meantime, not likely to be terribly widespread. > > Cheers, > Mike > > > > ------------------------------ > > Message: 3 > Date: Wed, 21 Apr 2004 01:52:14 -0700 > From: mike wakerly > Subject: Re: [Csci551-talk] strange article.. > To: Rahul Pilani > Cc: csci551-talk@mailman.isi.edu > Message-ID: <2F4D95AE-9371-11D8-8E13-000A95A6AAA6@usc.edu> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Apr 21, 2004, at 1:21 AM, Rahul Pilani wrote: > > Watson said he can guess the proper number with as few as four > > attempts, which can be accomplished within seconds. > > PS: From this admission, you can guess that he found a TCP > implementation that accepts any sequence number within an 8-bit window. > (First guess is in [0,2**8)], next in [2**8,2**16), and so on..) > > Cheers, > Mike > > > > ------------------------------ > > Message: 4 > Date: Wed, 21 Apr 2004 02:13:58 -0700 > From: rajesh shroff > Subject: Re: [Csci551-talk] strange article.. > To: mike wakerly > Cc: csci551-talk@ISI.EDU > Message-ID: <9ed98f012400.4085d8e6@usc.edu> > Content-Type: text/plain; charset=us-ascii > > Dampening is a feature introduced for the routing protocols to consider a > router down and not available for routing of packets till that router is > stable (no flapping). > Browsing further through the CISCO IOS SOFTWARE RELEASES > Link: > http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bc8.html#wp1024977 > This para is imp: > The IP Event Dampening feature introduces a configurable exponential decay > mechanism to suppress the effects of excessive interface flapping events > on routing protocols and routing tables in the network. This feature > allows the network operator to configure a router to automatically > identify and selectively dampen a local interface that is flapping. > Dampening an interface removes the interface from the network until the > interface stops flapping and becomes stable. Configuring the IP Event > Dampening feature improves convergence times and stability throughout the > network by isolating failures so that disturbances are not propagated, > which reduces the utilization of system processing resources by other > devices in the network and improves overall network stability. > > After reading through this it also now makes sense with the statement in > the article as : > > """> > >>Continued successful attacks against routers can cause them to go > > > into a stand-by mode, known as "dampening," that can persist for > > > hours.""" > > So now as Mike said killing such an active BGP connection would cause > wider-spread disconnection -- at least until, say, withdrawn routes are re- > advertised. > And as per this feature of dampening, this perticular router will not be > available to the network for routing purposes and hence will disrupt the > normal routing procedure. > > does this not make more sense now..... > > > ----- Original Message ----- > From: mike wakerly > Date: Wednesday, April 21, 2004 1:44 am > Subject: Re: [Csci551-talk] strange article.. > > > On Apr 21, 2004, at 1:21 AM, Rahul Pilani wrote: > > > Is it similar to age-old hacking techniques like buffer-overflow etc?.. > > > > No, the flaw is not nearly as general. It seems that many TCP stacks > > incorrectly handle RST commands in a TCP connection, and as a > > consequence, could be tricked into closing a connection. It is > > important to realize that this seems to be an implementation flaw -- > > TCP doesn't need to be changed, but some stacks may. > > > > > >>Routers continually exchange important updates about the most > > > efficient traffic routes between large networks. > > > > > > How is exchanging routes concerned with TCP ? > > > I think what the so called "Technical Writer" is referring to some > > > routing protocol like BGP.. > > > > Right, I think something I read earlier today about this mentioned BGP > > explicitly. Whatever that article was, it suggested BGP connections > > could be targeted because (1) they are generally left open (eg, > > long-lived), and (2) resetting and hence killing such a connection > > could cause wider-spread disconnection -- at least until, say, > > withdrawn routes are re-advertised. > > > > > >>Continued successful attacks against routers can cause them to go > > > into a stand-by mode, known as "dampening," that can persist for > > > hours. > > > > > > What is the dampening mode that is being talked about?.. Is it OS > > > specific or is part of any protocol? > > > > No idea :) > > > > > >>Experts previously maintained such attacks could take between four > > > to 142 years to succeed because they require guessing a rotating > > > number from > > > >>roughly 4 billion possible combinations. Watson said he can guess > > > the proper number with as few as four attempts, which can be > > > accomplished within seconds. > > > > > > Combinations of what?.. > > > Does anybody have anymore details of what this article is all about?? > > > or is it just paranoia?.. > > > > To simplify, injecting a packet into a TCP flow is hard because > > predicting the sequence number is hard. The flaw here is that someone > > observed a TCP implementation that accepts RST packets with not only > > the next sequence number, but any sequence number within a certain > > window. By reducing the space of acceptable sequence numbers, the > > difficulty in injecting a packet is reduced. > > > > I'd say this is mostly paranoia. It's an easy problem to fix, and in > > the meantime, not likely to be terribly widespread. > > > > Cheers, > > Mike > > > > > > > > ------------------------------ > > _______________________________________________ > Csci551-talk mailing list > Csci551-talk@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/csci551-talk > > > End of Csci551-talk Digest, Vol 4, Issue 14 > ******************************************* > From mqin at usc.edu Thu Apr 22 00:31:14 2004 From: mqin at usc.edu (min) Date: Thu Apr 22 00:34:36 2004 Subject: [Csci551-talk] stage7 input Message-ID: <003601c4283b$cb039e50$ec267f44@jimmy> Hi, all What will stage 7 input looks like? i think it should be similar to stage 6, but the handout say "otherwise you should have all the same output as stage-5". Also, for stage 7, it said "for every 3 data packets it forwards it should increase MED by 1". Only "forwards", not including "originated" and "sent", am i right? Cheers Min Qin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20040422/ec042277/attachment-0001.html From atu011 at earthlink.net Thu Apr 22 11:10:14 2004 From: atu011 at earthlink.net (Aaron Tu) Date: Thu Apr 22 11:10:43 2004 Subject: [Csci551-talk] building sample proja with cygwin In-Reply-To: <200404220734.i3M7Ya203731@gamma.isi.edu> Message-ID: <000201c42895$12558850$7a503e9f@LATUALP> Has anybody successfully rebuild sample Project A with Cygwin? I have the following error message: g++ -g -Wall -c gen.cc In file included from gen.cc:26: gen.hh:58: error: ISO C++ forbids declaration of `ostream' with no type gen.hh:58: error: `ostream' is neither function nor member function; cannot be declared friend gen.hh:58: error: syntax error before `&' token gen.hh:91: error: ISO C++ forbids declaration of `ostream' with no type gen.hh:91: error: `ostream' is neither function nor member function; cannot be declared friend gen.hh:91: error: syntax error before `&' token gen.hh:101: error: 'list' is used as a type, but is not defined as a type. gen.hh:102: error: 'list' is used as a type, but is not defined as a type. gen.hh:113: error: syntax error before `&' token gen.hh: In member function `void BaseRouter::add_internal_route(Route*)': gen.hh:106: error: `internal_routes_' undeclared (first use this function) gen.hh:106: error: (Each undeclared identifier is reported only once for each function it appears in.) gen.hh: In member function `void BaseRouter::add_external_route(Route*)': gen.hh:107: error: `external_routes_' undeclared (first use this function) gen.hh: In member function `Route* BaseRouter::internal_route()': gen.hh:110: error: `assert' undeclared (first use this function) gen.hh: At global scope: gen.hh:114: error: syntax error before `}' token gen.hh:126: error: ISO C++ forbids declaration of `ostream' with no type gen.hh:126: error: `ostream' is neither function nor member function; cannot be declared friend gen.hh:126: error: syntax error before `&' token gen.hh: In member function `void RouterStats::bump(RouterStats::stat_enum)': gen.hh:124: error: `assert' undeclared (first use this function) gen.cc: At global scope: gen.cc:39: error: syntax error before `&' token gen.cc:51: error: syntax error before `&' token gen.cc:55: error: syntax error before `;' token gen.cc:55: error: syntax error before `++' token gen.cc:75: error: syntax error before `&' token make: *** [gen.o] Error 1 $ Do I need to set up special path? Aaron From atu011 at earthlink.net Thu Apr 22 18:28:42 2004 From: atu011 at earthlink.net (Aaron Tu) Date: Thu Apr 22 18:30:41 2004 Subject: [Csci551-talk] RE: Csci551-talk Digest, Vol 4, Issue 16 In-Reply-To: <200404221900.i3MJ0M208989@gamma.isi.edu> Message-ID: <000301c428d2$509c4bc0$7a503e9f@LATUALP> Sample Project A breaks when compiled with g++ 3.3.1. I was able to fix some of the problems and successfully compiled the code, but I'm having problem with the assert(). The socket functions core dump when I try to run the program in Cygwin. Does anybody know what's going on? I don't have any problem with the socket when I wrote my code in c. Does c++ treats socket differently? Aaron -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of csci551-talk-request@mailman.isi.edu Sent: Thursday, April 22, 2004 12:00 PM To: csci551-talk@mailman.isi.edu Subject: Csci551-talk Digest, Vol 4, Issue 16 Send Csci551-talk mailing list submissions to csci551-talk@mailman.isi.edu To subscribe or unsubscribe via the World Wide Web, visit http://mailman.isi.edu/mailman/listinfo/csci551-talk or, via email, send a message with subject or body 'help' to csci551-talk-request@mailman.isi.edu You can reach the person managing the list at csci551-talk-owner@mailman.isi.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of Csci551-talk digest..." Today's Topics: 1. building sample proja with cygwin (Aaron Tu) ---------------------------------------------------------------------- Message: 1 Date: Thu, 22 Apr 2004 11:10:14 -0700 From: "Aaron Tu" Subject: [Csci551-talk] building sample proja with cygwin To: Message-ID: <000201c42895$12558850$7a503e9f@LATUALP> Content-Type: text/plain; charset="us-ascii" Has anybody successfully rebuild sample Project A with Cygwin? I have the following error message: g++ -g -Wall -c gen.cc In file included from gen.cc:26: gen.hh:58: error: ISO C++ forbids declaration of `ostream' with no type gen.hh:58: error: `ostream' is neither function nor member function; cannot be declared friend gen.hh:58: error: syntax error before `&' token gen.hh:91: error: ISO C++ forbids declaration of `ostream' with no type gen.hh:91: error: `ostream' is neither function nor member function; cannot be declared friend gen.hh:91: error: syntax error before `&' token gen.hh:101: error: 'list' is used as a type, but is not defined as a type. gen.hh:102: error: 'list' is used as a type, but is not defined as a type. gen.hh:113: error: syntax error before `&' token gen.hh: In member function `void BaseRouter::add_internal_route(Route*)': gen.hh:106: error: `internal_routes_' undeclared (first use this function) gen.hh:106: error: (Each undeclared identifier is reported only once for each function it appears in.) gen.hh: In member function `void BaseRouter::add_external_route(Route*)': gen.hh:107: error: `external_routes_' undeclared (first use this function) gen.hh: In member function `Route* BaseRouter::internal_route()': gen.hh:110: error: `assert' undeclared (first use this function) gen.hh: At global scope: gen.hh:114: error: syntax error before `}' token gen.hh:126: error: ISO C++ forbids declaration of `ostream' with no type gen.hh:126: error: `ostream' is neither function nor member function; cannot be declared friend gen.hh:126: error: syntax error before `&' token gen.hh: In member function `void RouterStats::bump(RouterStats::stat_enum)': gen.hh:124: error: `assert' undeclared (first use this function) gen.cc: At global scope: gen.cc:39: error: syntax error before `&' token gen.cc:51: error: syntax error before `&' token gen.cc:55: error: syntax error before `;' token gen.cc:55: error: syntax error before `++' token gen.cc:75: error: syntax error before `&' token make: *** [gen.o] Error 1 $ Do I need to set up special path? Aaron ------------------------------ _______________________________________________ Csci551-talk mailing list Csci551-talk@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/csci551-talk End of Csci551-talk Digest, Vol 4, Issue 16 ******************************************* From atu011 at earthlink.net Thu Apr 22 18:42:22 2004 From: atu011 at earthlink.net (Aaron Tu) Date: Thu Apr 22 18:42:35 2004 Subject: [Csci551-talk] installing g++ 2.95.2 In-Reply-To: <200404221900.i3MJ0M208989@gamma.isi.edu> Message-ID: <000401c428d4$3908c3b0$7a503e9f@LATUALP> Does anyone know where I can find g++ 2.95.2 for Cygwin? Is it possible to have both versions installed on the same machine? Aaron From atu011 at earthlink.net Thu Apr 22 21:21:36 2004 From: atu011 at earthlink.net (Aaron Tu) Date: Thu Apr 22 21:22:42 2004 Subject: [Csci551-talk] Got my problem fixed!!! In-Reply-To: <200404221900.i3MJ0M208989@gamma.isi.edu> Message-ID: <000a01c428ea$77adbe70$7a503e9f@LATUALP> For those who are planning to use the sample project, I believe lines 134-5 in router.cc should be swapped. memset(&udp_sa, 0, sizeof(udp_sa)); udp_sa.sin_family = AF_INET; I'm surprised that g++ 2.95.2 did not catch this in Aludra, but g++ 3.3.1 did in Cygwin. Well, the program core dumped. Hmmmm. Could AF_INET be zero on Aludra and not in Cygwin??? Aaron From coolrocks at tom.com Sat Apr 24 23:41:25 2004 From: coolrocks at tom.com (Coolrocks) Date: Sat Apr 24 23:43:24 2004 Subject: [Csci551-talk] MED & load sensitive routing in proj B Message-ID: <003401c42a90$5b9a1ba0$6500a8c0@coolrocks> Hi all, Reading the specs for "sensitive routing" and "oscillation" in project B, I got confused with MED. Is MED an attribute for a link. I.e. between neighbor routers? or for one of the "routes"(prefix/mask pair) which a "router" is responsible for ? My doubts came from the following: I refered to the specs in project A and it seemed that MED is defined as (see, 3rd paragraph in subsection 5 in project A specs). If using this definition in Project B, one only needs to change the MED for an internal route (the one and only prefix/mask pair) which the router is responsible for. But the question is, if this is the case, it won't be necessary to run link-state routing at all! Link-state routing is run when a router's links' "states" change (i.e neighbor router up or down, etc). In our case, none of the links' states has changed since there are no two routers routing to the same prefix/mask pair, there won't be a prefered link to choose (unlike in project A where there are two or more external routers routing to the same AS where we need to make a routing decision). No matter what the MED value of the route has changed to, everyone will still have to route through that router to reach that domain. If MED is for a link, which is different from project A, do all the links from a router take the same value, or each link has its own MED value? If the latter, how should one allocate the changes among links? Please comment and enlighten! Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20040424/3296114d/attachment.html From coolrocks at tom.com Sun Apr 25 08:55:44 2004 From: coolrocks at tom.com (Coolrocks) Date: Sun Apr 25 20:19:03 2004 Subject: [Csci551-talk] MED & load sensitive routing in proj B References: <1fec4cbb30ae.408b529e@usc.edu> Message-ID: <001a01c42add$e3f79890$6500a8c0@coolrocks> Doesn't this mean that we need to modify the whole link-state routing code in proj A for proj B?? ----- Original Message ----- From: "parag shah" To: "Coolrocks" Sent: Sunday, April 25, 2004 5:54 AM Subject: Re: [Csci551-talk] MED & load sensitive routing in proj B > in this proj med is for a router > > ----- Original Message ----- > From: Coolrocks > Date: Saturday, April 24, 2004 11:41 pm > Subject: [Csci551-talk] MED & load sensitive routing in proj B > > > Hi all, > > Reading the specs for "sensitive routing" and "oscillation" in project > > B, I got confused with MED. Is MED an attribute for > > > > a link. I.e. between neighbor routers? or > > for one of the "routes"(prefix/mask pair) which a "router" is > > responsible for ? > > > > My doubts came from the following: > > I refered to the specs in project A and it seemed that MED is defined > > as (see, 3rd paragraph in subsection 5 in project A specs). If using > > this definition in Project B, one only needs to change the MED for an > > internal route (the one and only prefix/mask pair) which the router is > > responsible for. But the question is, if this is the case, it won't be > > necessary to run link-state routing at all! Link-state routing is run when > > a router's links' "states" change (i.e neighbor router up or down, etc). > > In our case, none of the links' states has changed since there are no two > > routers routing to the same prefix/mask pair, there won't be a prefered > > link to choose (unlike in project A where there are two or more external > > routers routing to the same AS where we need to make a routing decision). > > No matter what the MED value of the route has changed to, everyone will > > still have to route through that router to reach that domain. > > If MED is for a link, which is different from project A, do all the > > links from a router take the same value, or each link has its own MED > > value? If the latter, how should one allocate the changes among links? > > > > Please comment and enlighten! > > Thanks! > > > > > > > > > From bshukla at usc.edu Mon Apr 26 01:18:46 2004 From: bshukla at usc.edu (bhavin shukla) Date: Mon Apr 26 01:19:27 2004 Subject: [Csci551-talk] stage 6 Message-ID: Hi, I had a question on stage 6 where every router is supposed tt print statements like: 1)sending data from host h1 to host h2 2)forwarding data from host h1 to host h2 3)received data from host h1 to host h2 I want to know if h1 and h2 refer to the origin and the destination that is the ips specified in the config file OR is h1:the ip of the neighboring router who fwded this packet to this router and h2 the ip of the router to whom this router will fwd the packet? eg. if 1 needs to send to 6 thru 3 and then 4 then wat is h1 and h2 at router 3? thanks, Bhavin Shukla Graduate Student in the Computer Science Department University of Southern California http://www-scf.usc.edu/~bshukla/ From devarshi at ieee.org Mon Apr 26 02:39:23 2004 From: devarshi at ieee.org (Devarshi Shah) Date: Mon Apr 26 02:41:27 2004 Subject: [Csci551-talk] MED & load sensitive routing in proj B In-Reply-To: <001a01c42add$e3f79890$6500a8c0@coolrocks> Message-ID: No - you do not need to modify the routing code. The med value in project A was for a particular subset of the IP ranges managed by that router. Thus, if a router was managing (or aggregating) 192.168.0.0/16 and 10.1.0.0/16, it could have two different med values, one for each of the above networks. So, from my understanding of the project definition, every time you forward 3 packets, you increase the med values for all the networks you handle. The reason why you would want to send out LSA messages after increasing your med is to let others know about it so that they could now choose a lower med route if it is available. Having said that, the only case in which this sort of scheme would perform load sensitive routing is if multiple routers were responsible for the same network i.e. it would work only if say, for example, both A and B could route to 192.16.0.0/16. Also, this implies that part 5, the route oscillations, can never be caused by using the given topology, because each router is responsible only for 1 network. I guess for load sensitive routing to work in that case, an additional field for link weightage needs to be added and factored in. Could anyone please care to correct me if I am wrong in my reasoning ? --Devarshi Devarshi P. Shah -------------------------------------------------------------- Graduate Student (Computer Science), University of Southern California, LA. -------------------------------------------------------------- Web : http://devarshi.shah.name email : devarshi@shah.name Cell : 323-363-3791, Home :323-373-0318 -------------------------------------------------------------- -----Original Message----- From: csci551-talk-bounces@mailman.isi.edu [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of Coolrocks Sent: Sunday, April 25, 2004 8:56 AM To: parag shah Cc: csci551-talk@ISI.EDU Subject: Re: [Csci551-talk] MED & load sensitive routing in proj B Doesn't this mean that we need to modify the whole link-state routing code in proj A for proj B?? ----- Original Message ----- From: "parag shah" To: "Coolrocks" Sent: Sunday, April 25, 2004 5:54 AM Subject: Re: [Csci551-talk] MED & load sensitive routing in proj B > in this proj med is for a router > > ----- Original Message ----- > From: Coolrocks > Date: Saturday, April 24, 2004 11:41 pm > Subject: [Csci551-talk] MED & load sensitive routing in proj B > > > Hi all, > > Reading the specs for "sensitive routing" and "oscillation" in project > > B, I got confused with MED. Is MED an attribute for > > > > a link. I.e. between neighbor routers? or > > for one of the "routes"(prefix/mask pair) which a "router" is > > responsible for ? > > > > My doubts came from the following: > > I refered to the specs in project A and it seemed that MED is defined > > as (see, 3rd paragraph in subsection 5 in project A specs). If using > > this definition in Project B, one only needs to change the MED for an > > internal route (the one and only prefix/mask pair) which the router is > > responsible for. But the question is, if this is the case, it won't be > > necessary to run link-state routing at all! Link-state routing is run when > > a router's links' "states" change (i.e neighbor router up or down, etc). > > In our case, none of the links' states has changed since there are no two > > routers routing to the same prefix/mask pair, there won't be a prefered > > link to choose (unlike in project A where there are two or more external > > routers routing to the same AS where we need to make a routing decision). > > No matter what the MED value of the route has changed to, everyone will > > still have to route through that router to reach that domain. > > If MED is for a link, which is different from project A, do all the > > links from a router take the same value, or each link has its own MED > > value? If the latter, how should one allocate the changes among links? > > > > Please comment and enlighten! > > Thanks! > > > > > > > > > From paragsha at usc.edu Mon Apr 26 07:30:56 2004 From: paragsha at usc.edu (parag shah) Date: Mon Apr 26 07:31:32 2004 Subject: [Csci551-talk] med updates Message-ID: do we have to send a LS packet for the med update or we can just create a new packet format which will have only the updated med vlaue. thanks From coolrocks at tom.com Mon Apr 26 08:11:27 2004 From: coolrocks at tom.com (Coolrocks) Date: Mon Apr 26 08:17:35 2004 Subject: [Csci551-talk] MED & load sensitive routing in proj B References: Message-ID: <001e01c42ba0$c91bcaa0$6500a8c0@coolrocks> In this case, in order to do load sensitive routing, besides adding another field, maybe one router can just adjust the "cost" for all links to its neighbors (orginally they were all 1)? What do you think? ----- Original Message ----- From: "Devarshi Shah" To: Cc: "'John Heidemann'" Sent: Monday, April 26, 2004 2:39 AM Subject: RE: [Csci551-talk] MED & load sensitive routing in proj B > No - you do not need to modify the routing code. The med value in project A > was for a particular subset of the IP ranges managed by that router. Thus, > if a router was managing (or aggregating) 192.168.0.0/16 and 10.1.0.0/16, it > could have two different med values, one for each of the above networks. > > So, from my understanding of the project definition, every time you forward > 3 packets, you increase the med values for all the networks you handle. The > reason why you would want to send out LSA messages after increasing your med > is to let others know about it so that they could now choose a lower med > route if it is available. Having said that, the only case in which this sort > of scheme would perform load sensitive routing is if multiple routers were > responsible for the same network i.e. it would work only if say, for > example, both A and B could route to 192.16.0.0/16. > > Also, this implies that part 5, the route oscillations, can never be caused > by using the given topology, because each router is responsible only for 1 > network. I guess for load sensitive routing to work in that case, an > additional field for link weightage needs to be added and factored in. > > Could anyone please care to correct me if I am wrong in my reasoning ? > > --Devarshi > > Devarshi P. Shah > -------------------------------------------------------------- > Graduate Student (Computer Science), > University of Southern California, LA. > -------------------------------------------------------------- > Web : http://devarshi.shah.name > email : devarshi@shah.name > Cell : 323-363-3791, Home :323-373-0318 > -------------------------------------------------------------- > > > -----Original Message----- > From: csci551-talk-bounces@mailman.isi.edu > [mailto:csci551-talk-bounces@mailman.isi.edu] On Behalf Of Coolrocks > Sent: Sunday, April 25, 2004 8:56 AM > To: parag shah > Cc: csci551-talk@ISI.EDU > Subject: Re: [Csci551-talk] MED & load sensitive routing in proj B > > Doesn't this mean that we need to modify the whole link-state routing code > in proj A for proj B?? > > ----- Original Message ----- > From: "parag shah" > To: "Coolrocks" > Sent: Sunday, April 25, 2004 5:54 AM > Subject: Re: [Csci551-talk] MED & load sensitive routing in proj B > > > > in this proj med is for a router > > > > ----- Original Message ----- > > From: Coolrocks > > Date: Saturday, April 24, 2004 11:41 pm > > Subject: [Csci551-talk] MED & load sensitive routing in proj B > > > > > Hi all, > > > Reading the specs for "sensitive routing" and "oscillation" in > project > > > B, I got confused with MED. Is MED an attribute for > > > > > > a link. I.e. between neighbor routers? or > > > for one of the "routes"(prefix/mask pair) which a "router" is > > > responsible for ? > > > > > > My doubts came from the following: > > > I refered to the specs in project A and it seemed that MED is defined > > > as (see, 3rd paragraph in subsection 5 in project A specs). If using > > > this definition in Project B, one only needs to change the MED for an > > > internal route (the one and only prefix/mask pair) which the router is > > > responsible for. But the question is, if this is the case, it won't be > > > necessary to run link-state routing at all! Link-state routing is run > when > > > a router's links' "states" change (i.e neighbor router up or down, etc). > > > In our case, none of the links' states has changed since there are no > two > > > routers routing to the same prefix/mask pair, there won't be a prefered > > > link to choose (unlike in project A where there are two or more external > > > routers routing to the same AS where we need to make a routing > decision). > > > No matter what the MED value of the route has changed to, everyone will > > > still have to route through that router to reach that domain. > > > If MED is for a link, which is different from project A, do all the > > > links from a router take the same value, or each link has its own MED > > > value? If the latter, how should one allocate the changes among links? > > > > > > Please comment and enlighten! > > > Thanks! > > > > > > > > > > > > > > > > > > > > From johnh at ISI.EDU Mon Apr 26 14:15:38 2004 From: johnh at ISI.EDU (John Heidemann) Date: Mon Apr 26 14:18:02 2004 Subject: [Csci551-talk] the recent TCP RST problem Message-ID: <200404262115.i3QLFcRE003918@dash.isi.edu> (Taking a break from the host of Proj B related mail, which I'll get to next :-) Bhavin Shukla's description of the problem was basically right: He wrote: >The TPC manages the flow of data packets across the internet. It >includes a design feature that allows a TCP communications session to >be reset remotely across a network. Sending a reset command depends >upon using the correct communications "port", which is set at random >by the router beforehand. Previously, the odds of simply guessing this >port were thought to be unrealistically high - about one in four >billion. > >NOw Paul Watson, an independent computer security consultant based in >the US, discovered that just a portion of the correct number will >work. This means a valid reset command could be sent in just a few >tries. And repeatedly sending reset commands to carefully chosen >routers could prevent network traffic from being forwarded, leaving >computers unable to communicate. By design, you can send a RST to a TCP connection to tear it down. This is a feature intended to handle "bad things". For example, when you hit "cancel" in a web browser, your computer sends a RST to the other end to clean things up. This feature is considered a Good Thing and dates back to the TCP spec (RFC-793). The spec also says that you only honor a RST if it's in the current window. It's also well known that TCP is vulnerable to forged packet insertions. That's part of what IPSec solves (by using Real Crypto). Thus, it was previuosly known that anyone can tear down a TCP connection by forging a RST packet to it. However, it was assumed that that was difficult to do in practice because you had to guess both port numbers and a sequence number in the current window. I.e., guessing a number in a space of 2^16 * 2^16 * 2^(16-10) (or so). (Assuming the window was 2^10.) This was considered Pretty Hard To Do. The New Problem that's discussed in Watson's paper is that this is easier to do than previously thought. (I should say, I presume this is what's in Watson's paper; I haven't actually seen it yet.) is the observation as best I know that, for BGP connnections, (1) you can often find out the port numbers through out-of-band means. And (2) windows are now bigger than they used to be (2^15 rather than 2^10). Now the problem requires probing 1 * 1 * 2^(16-15) = 2 numbers! This is considered Not So Hard. And the Further Problem is that if you take down a BGP connection, it assumes the link is down (recall Shaikh et al from class). It will restart, but you can keep taking it down. So without too much difficulty you could disrupt links between routers, using a couple of packets with forged addresses. This is considered Very Bad. Fortunately, there are several fixes, some of which seem reasonably easy to implement. One fix is to switch the routers to using IPSec. This is probably hard because IPSec is pretty involved. Another fix is to do ingress and egress filtering. Reject packets coming into or leaving your net that have forged source/destination addresses. This is a Good Thing (it also helps prevent DDoS), but it's impossible to implement because it requires that everyone do it for it to work. Finally, it turns out there are some simple changes to TCP RST processing that can avoid most of the problem. Basically, rather than trusting the RST anywhere in the window, make the sender get it exactly right. And (here's the tricky part) so so in a way that doesn't break unchanged clients. See ftp://ftp.isi.edu/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt for a description of the details. (And, oh, by the way, Ted Faber [the CS555 prof] is chairing the IETF working group discussing fixes to the problem. He helped fill me in on the current state of the problem.) -John Heidemann From stambe at usc.edu Mon Apr 26 14:28:31 2004 From: stambe at usc.edu (swara tambe) Date: Mon Apr 26 14:29:35 2004 Subject: [Csci551-talk] project B-stage 5 Message-ID: <86556a7d26e4.408d1c8f@usc.edu> Hi, I have a few doubts about stage 5 for project B. What if you have two routers: 192.168.200.0 24 192.168.200.128 25 Now, what if you have to route to 192.168.200.255. Will the destination then be the first router or the second one? Also, what does it mean by "you may assume that you do not need to do longest prefix matches-you won't have any cases where multiple routers manage overlapping parts of the address space". I am kind of unsure about this and would appreciate if someone could help clarify my doubts. Thanks, Swara From coolrocks at tom.com Mon Apr 26 15:57:30 2004 From: coolrocks at tom.com (Coolrocks) Date: Mon Apr 26 15:59:38 2004 Subject: [Csci551-talk] project B-stage 5 References: <86556a7d26e4.408d1c8f@usc.edu> Message-ID: <005f01c42be1$dba62030$6500a8c0@coolrocks> I think the spec means that there will be no such routing entries (as you have specified) in our routing tables. Or, any IP that masks with the prefix will have "only one" router that is responsible for (i.e."won't have any cases where multiple routers manage overlapping parts of the address space"). This implies that a simple linear search and match in the routing table will solve our problem. Note that in reality, in the case u mentioned, when making such a routing decision one would choose to route to the router that is responsible for "192.168.200.128 25" which has the "longest prefix"(25>24). hope that helps:) ----- Original Message ----- From: "swara tambe" To: Sent: Monday, April 26, 2004 2:28 PM Subject: [Csci551-talk] project B-stage 5 > Hi, > > I have a few doubts about stage 5 for project B. What if you have two routers: > > 192.168.200.0 24 > 192.168.200.128 25 > > Now, what if you have to route to 192.168.200.255. Will the destination then be the first router or the second one? > > Also, what does it mean by "you may assume that you do not need to do longest prefix matches-you won't have any cases where multiple routers manage overlapping parts of the address space". > > I am kind of unsure about this and would appreciate if someone could help clarify my doubts. > > Thanks, > Swara > > > From liyuan at pollux.usc.edu Mon Apr 26 16:42:20 2004 From: liyuan at pollux.usc.edu (Yuan Li) Date: Mon Apr 26 16:43:31 2004 Subject: [Csci551-talk] Special office hour today Message-ID: Dear Class, I will hold special office hours at my office today at 5:30pm. So please come to see me if you have any questions regarding the grades. Thanks Yuan From jpatil at usc.edu Tue Apr 27 01:24:02 2004 From: jpatil at usc.edu (jayesh patil) Date: Tue Apr 27 01:25:33 2004 Subject: [Csci551-talk] Error running ProjectA sample code Message-ID: <42502a324f71.408db632@usc.edu> Hi There's a problem i am facing while running the sample code for projectA given to us. main.cc:73: failed assertion 'config_stream.good()' Has anyone figured out a way to solve it?? Thanks, Jayesh. From jpatil at usc.edu Tue Apr 27 01:26:09 2004 From: jpatil at usc.edu (jayesh patil) Date: Tue Apr 27 01:27:34 2004 Subject: [Csci551-talk] Error running sample project A code Message-ID: <43ffffe05c45.408db6b1@usc.edu> Hi There's a problem i am facing while running the sample code for projectA given to us. main.cc:73: failed assertion 'config_stream.good()' Has anyone figured out a way to solve it?? Thanks, Jayesh. Masters - Computer Science University of Southern California Los Angeles, California - 90007 Tel No : (323)620-4472 LIVE LIFE KINGSIZE From johnh at ISI.EDU Tue Apr 27 11:38:53 2004 From: johnh at ISI.EDU (John Heidemann) Date: Tue Apr 27 11:43:21 2004 Subject: [Csci551-talk] Part 4 : regarding sending data packets In-Reply-To: <1082260616.8007.6.camel@maverick> Message-ID: <200404271838.i3RIcrK6024366@dash.isi.edu> On Sat, 17 Apr 2004 20:56:56 PDT, Devarshi Shah wrote: >Hi, > >I had a question regarding the sending of data packets in part 4. If >suppose we have a couple of consecutive sends, and they cause the MED to >change, are we supposed to continue sending the remaining data packets >without waiting for the routing tables to stabilize following the MED >value changes ? Or, are we expected to wait for the routing tables to >re-stabilize once the MED values change before we continue sending more >data packets ? > >Thanks, >Devarshi We discussed this briefly after the last class (or possibly I discussed this only with some individuals). We need to have consistent results across everyone's programs to make them gradable. Currently the only time the Proj A spec requires routes to converge is after a "w" command. For "s" commands, it only says this weaker thing: There may be multiple "send" lines in a row. If so, you may choose to pause briefly between them to give packets time to travel. Thus, we have a dilemma. First, it is not wrong for you to ensure that routing tables converge after any command. (But this is not required by the spec.) However, we must ensure that our input files converge regardless of what you do. So we will do so using the tools at our command (the input files). -John Heidemann From johnh at ISI.EDU Tue Apr 27 11:38:44 2004 From: johnh at ISI.EDU (John Heidemann) Date: Tue Apr 27 11:43:23 2004 Subject: [Csci551-talk] Re: MED & load sensitive routing in proj B In-Reply-To: <003401c42a90$5b9a1ba0$6500a8c0@coolrocks> Message-ID: <200404271838.i3RIcj2V024352@dash.isi.edu> On Sat, 24 Apr 2004 23:41:25 PDT, "Coolrocks" wrote: >Hi all, > Reading the specs for "sensitive routing" and "oscillation" in project >B, I got confused with MED. Is MED an attribute for > > a link. I.e. between neighbor routers? or > for one of the "routes"(prefix/mask pair) which a "router" is >responsible for ? > >My doubts came from the following: > I refered to the specs in project A and it seemed that MED is defined as >(see, 3rd paragraph in subsection 5 in project A specs). If using this >definition in Project B, one only needs to change the MED for an internal >route (the one and only prefix/mask pair) which the router is responsible >for. But the question is, if this is the case, it won't be necessary to run >link-state routing at all! Link-state routing is run when a router's >links' "states" change (i.e neighbor router up or down, etc). In our case, >none of the links' states has changed since there are no two routers routing >to the same prefix/mask pair, there won't be a prefered link to choose >(unlike in project A where there are two or more external routers routing to >the same AS where we need to make a routing decision). No matter what the >MED value of the route has changed to, everyone will still have to route >through that router to reach that domain. > If MED is for a link, which is different from project A, do all the >links from a router take the same value, or each link has its own MED value? >If the latter, how should one allocate the changes among links? Yes, currently that part of the specification is incomplete and has a bug (as it's currently written). First, to clarify MED values: they're properties of prefixes, just as in Project A. So when the spec says a router should increase "its MED value", a better way to put that would be "it should increase the MED value of all prefixes for which it is responsible". This part was not as clear as it could have been. But this leads to a second problem which you describe: if there's only one destination, than changing the MED value won't amke any difference. This part is the specification bug. A rough description of the fix: you should assume that you will have multiple routers that will be responsible for the same prefix. Then you can demonstrate load senstive routing as defined. (Ideally I'd do this with external routes, but since I've already said that external routes are not required in Proj B, I won't change that. Therefore you should assume that input files will have multiple routers responsible for the same route. This is kind of broken, but it's the least disruptive fix for this specification bug.) THis is just a rough description. I will update the project later today to clarify how this should be handled, and to include sample inputs and outputs. Thanks for catching this specification bug; my apologies for not catching it earlier. -John Heidemann From johnh at ISI.EDU Tue Apr 27 11:42:10 2004 From: johnh at ISI.EDU (John Heidemann) Date: Tue Apr 27 11:43:42 2004 Subject: [Csci551-talk] med updates In-Reply-To: Message-ID: <200404271842.i3RIgA4Z024414@dash.isi.edu> On Mon, 26 Apr 2004 07:30:56 PDT, parag shah wrote: >do we have to send a LS packet for the med update or we can just create a new packet format which will have only the updated med vlaue. > >thanks Unless you have a good reason to do otherwise, you should use the existing routing infrastructure/LS messages. -John Heidemann From johnh at ISI.EDU Tue Apr 27 11:41:14 2004 From: johnh at ISI.EDU (John Heidemann) Date: Tue Apr 27 11:43:44 2004 Subject: [Csci551-talk] MED & load sensitive routing in proj B In-Reply-To: Message-ID: <200404271841.i3RIfEoD024392@dash.isi.edu> On Mon, 26 Apr 2004 02:39:23 PDT, "Devarshi Shah" wrote: >No - you do not need to modify the routing code. The med value in project A >was for a particular subset of the IP ranges managed by that router. Thus, >if a router was managing (or aggregating) 192.168.0.0/16 and 10.1.0.0/16, it >could have two different med values, one for each of the above networks. > >So, from my understanding of the project definition, every time you forward >3 packets, you increase the med values for all the networks you handle. The >reason why you would want to send out LSA messages after increasing your med >is to let others know about it so that they could now choose a lower med >route if it is available. Having said that, the only case in which this sort >of scheme would perform load sensitive routing is if multiple routers were >responsible for the same network i.e. it would work only if say, for >example, both A and B could route to 192.16.0.0/16. > >Also, this implies that part 5, the route oscillations, can never be caused >by using the given topology, because each router is responsible only for 1 >network. I guess for load sensitive routing to work in that case, an >additional field for link weightage needs to be added and factored in. > >Could anyone please care to correct me if I am wrong in my reasoning ? > Your statements are correct, except that the fix is that a multiple routers will be responsible for a single prefix. -John Heidemann From johnh at ISI.EDU Tue Apr 27 11:42:55 2004 From: johnh at ISI.EDU (John Heidemann) Date: Tue Apr 27 11:45:41 2004 Subject: [Csci551-talk] MED & load sensitive routing in proj B In-Reply-To: <001e01c42ba0$c91bcaa0$6500a8c0@coolrocks> Message-ID: <200404271842.i3RIgtoa024433@dash.isi.edu> On Mon, 26 Apr 2004 08:11:27 PDT, "Coolrocks" wrote: >In this case, in order to do load sensitive routing, besides adding another >field, maybe one router can just adjust the "cost" for all links to its >neighbors (orginally they were all 1)? > >What do you think? That would be a very different routing algorithm, not what is intended for Proj B. -John Heidemann From johnh at ISI.EDU Tue Apr 27 11:44:23 2004 From: johnh at ISI.EDU (John Heidemann) Date: Tue Apr 27 11:45:51 2004 Subject: [Csci551-talk] project B-stage 5 In-Reply-To: <86556a7d26e4.408d1c8f@usc.edu> Message-ID: <200404271844.i3RIiNF3024452@dash.isi.edu> On Mon, 26 Apr 2004 14:28:31 PDT, swara tambe wrote: >Hi, > >I have a few doubts about stage 5 for project B. What if you have two routers: > >192.168.200.0 24 >192.168.200.128 25 > >Now, what if you have to route to 192.168.200.255. Will the destination then be the first router or the second one? > >Also, what does it mean by "you may assume that you do not need to do longest prefix matches-you won't have any cases where multiple routers manage overlapping parts of the address space". > >I am kind of unsure about this and would appreciate if someone could help clarify my doubts. > >Thanks, >Swara This is longest prefix matching. In the internet, you would prefer 192.168.200.128/25 to 192.168.200.0/24 because the /25 is more specific (it has a longer prefix). However, those cases are not required for this project. (You can assume they do not occur in the project input.) -John Heidemann From johnh at ISI.EDU Tue Apr 27 11:56:28 2004 From: johnh at ISI.EDU (John Heidemann) Date: Tue Apr 27 11:57:36 2004 Subject: [Csci551-talk] project b comment about handling input from TCP & UDP Message-ID: <200404271856.i3RIuSTi024511@dash.isi.edu> A student wrote me privately about the problem below. Since this is a problem multiple people face, I wanted to describe it on the mailing list (but I've anonymized the message): > Many of us have a problem concerning our project b, stage 7, here is it: > > Suppose the manager want to send data packet from router 1 to router 5, >and router 3 is in the middle between them. Since we have to use TCP to >communicate with the manager, so manager issued several TCP packets to >router1. when router 1 gets all the tcp packets, it will send out udp >packets destined to router 5. router 3 will forward those packets, and >changes its MED value. > So it send several new LSA packet to router1, however, at that time, >router 1 is still processing the tcp packets. after it processed all tcp >packets, it found that router 3 asked for route change, but at that time, >all the data packets are already delivered to the destination. So the MED >change has no effect on the data packets since they are already delivered. > > The major problem related to this is that both UDP and TCP are >implemented in an infinite loop. So if a router is listening to UDP port, it >cannot switch to TCP unless there is a timer callback(no udp message recved >for an amount of time). Changing the structure of our code seems very >troublesome. Could you help us clear this out? My comment: If you implement UDP and TCP each as separate infinite loops then you're correct that you can't handle input from either. Instead, you need to have ONE loop that handles input from BOTH sources--doing a select loop on both file descriptors and reading from whichever is ready. (I'm sorry if changing the structure of your code is troublesome, but that's unavoidable. In general, a server CANNOT block on one client unless its multi-threaded, and many high-performance servers are NOT one-thread per client because the overhead for that is too high.) -John Heidemann From johnh at ISI.EDU Tue Apr 27 17:15:33 2004 From: johnh at ISI.EDU (John Heidemann) Date: Tue Apr 27 17:17:37 2004 Subject: [Csci551-talk] office hours change this friday Message-ID: <200404280015.i3S0FXvV026830@dash.isi.edu> This Friday my office hours will be 12:15-1:45pm. -John Heidemann From johnh at ISI.EDU Tue Apr 27 17:41:53 2004 From: johnh at ISI.EDU (John Heidemann) Date: Tue Apr 27 17:43:46 2004 Subject: [Csci551-talk] update to project b specification Message-ID: <200404280041.i3S0frmn027251@dash.isi.edu> I've posted a tentative update to the Project B specification to the class web page. This should correct the bug in the load-senstitive routing part of the project. There may be minor changes tomorrow, in addition. -John Heidemann From rkulkarn at usc.edu Tue Apr 27 23:19:52 2004 From: rkulkarn at usc.edu (rohit kulkarni) Date: Tue Apr 27 23:21:39 2004 Subject: [Csci551-talk] a doubt in stage 6 Message-ID: <40b438db72f0.408eea98@usc.edu> Hello everyone, In stage 6 do we assume the the dest-ip would also exist or do we need to check as in stage 5. If we need to check then what should be done when dest-ip does not exist... i mean what needs to be printed to file and in what format ? Rohit From atu011 at earthlink.net Wed Apr 28 17:59:44 2004 From: atu011 at earthlink.net (Aaron Tu) Date: Wed Apr 28 18:01:43 2004 Subject: [Csci551-talk] 'w' instruction In-Reply-To: <200404271900.i3RJ07201130@gamma.isi.edu> Message-ID: <000001c42d85$435a05d0$7a503e9f@LATUALP> For Project A, all the processes exit when everything stabilized (timer expiration). Regarding to the 'w' instruction, will we be expecting a 'r' or 's' instruction to follow? Are we expected to handle packet transmission while the routing table is changing? Or do we wait until it stabilized? Aaron From atu011 at earthlink.net Wed Apr 28 22:58:48 2004 From: atu011 at earthlink.net (Aaron Tu) Date: Wed Apr 28 22:59:47 2004 Subject: [Csci551-talk] Question on Load Sensitive Routing Example In-Reply-To: <200404271900.i3RJ07201130@gamma.isi.edu> Message-ID: <00c701c42daf$0a5229a0$7a503e9f@LATUALP> For the updated example given in section 4: S 5 15.0.0.1 11.0.0.1 S 5 15.0.0.1 11.0.0.1 S 5 15.0.0.1 11.0.0.1 # after three packets, router 1 should up its MED value # and propagate this to other nodes Since router 3 and 5 forward the packet, should they up their MED values as well? Should we wait until the packet reaches its destination before propagating LSA message? Or should we start immediately? In this case, should router 5 initiate the LSA message while the packet is still trying to reach its destination? I think it would be much easier to what until the packet reaches its destination before propagating LSA message. Aaron From johnh at ISI.EDU Thu Apr 29 09:28:22 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 29 09:29:55 2004 Subject: [Csci551-talk] the recent TCP RST problem In-Reply-To: <200404262115.i3QLFcRE003918@dash.isi.edu> Message-ID: <200404291628.i3TGSMph019761@dash.isi.edu> Fixing an off-by-16 error in my prior post: On Mon, 26 Apr 2004 14:15:38 PDT, John Heidemann wrote: >... >Thus, it was previuosly known that anyone can tear down a TCP >connection by forging a RST packet to it. However, it was assumed >that that was difficult to do in practice because you had to guess >both port numbers and a sequence number in the current window. >I.e., guessing a number in a space of 2^16 * 2^16 * 2^(16-10) (or so). >(Assuming the window was 2^10.) >This was considered Pretty Hard To Do. That should be in a space of 2^16 * 2^16 * 2^(32-10) >... >The New Problem that's discussed in Watson's paper is that this is >easier to do than previously thought. (I should say, I presume this >is what's in Watson's paper; I haven't actually seen it yet.) > >is the observation as best I know that, for BGP connnections, (1) you can >often find out the port numbers through out-of-band means. And >(2) windows are now bigger than they used to be (2^15 rather than >2^10). Now the problem requires probing 1 * 1 * 2^(16-15) = 2 numbers! >This is considered Not So Hard. >... And these should be 1 * 1 * 2^(32-15) = 2^17, which is a lot more than 2 packets, but still not much at reasonable line rates (think about how long it would take at, say 256kb/s DSL-ish speeds). It would be interesting to see Watson's paper how he reduces it further. Certianly assuming a bigger window is possible. -John Heidemann From liyuan at pollux.usc.edu Thu Apr 29 11:29:34 2004 From: liyuan at pollux.usc.edu (Yuan Li) Date: Thu Apr 29 11:31:52 2004 Subject: [Csci551-talk] a doubt in stage 6 In-Reply-To: <40b438db72f0.408eea98@usc.edu> Message-ID: Since it is not mentioned in the spec, then we won't test this case in stage 6. Thanks Yuan On Tue, 27 Apr 2004, rohit kulkarni wrote: > Hello everyone, > > In stage 6 do we assume the the dest-ip would also exist or do we need to check as in stage 5. If we need to check then what should be done when dest-ip does not exist... i mean what needs to be printed to file and in what format ? > > Rohit > From johnh at ISI.EDU Thu Apr 29 12:51:51 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 29 12:54:16 2004 Subject: [Csci551-talk] a doubt in stage 6 In-Reply-To: Message-ID: <200404291951.i3TJppHC021056@dash.isi.edu> On Thu, 29 Apr 2004 11:29:34 PDT, Yuan Li wrote: > >Since it is not mentioned in the spec, then we won't test this case in >stage 6. > >Thanks > >Yuan > >On Tue, 27 Apr 2004, rohit kulkarni wrote: > >> Hello everyone, >> >> In stage 6 do we assume the the dest-ip would also exist or do we need to check as in stage 5. If we need to check then what should be done when dest-ip does not exist... i mean what needs to be printed to file and in what format ? >> >> Rohit >> I.e., you can make the same assumptions for stage 6 as for stage 5. (We will have tests for some things in stage 6 :-) -John Heidemann From johnh at ISI.EDU Thu Apr 29 18:17:57 2004 From: johnh at ISI.EDU (John Heidemann) Date: Thu Apr 29 18:19:47 2004 Subject: [Csci551-talk] final syllabus change Message-ID: <200404300117.i3U1Hvqj024057@dash.isi.edu> In reviewing [BenFredj01a], the analytic part of the paper requires concepts that we have not covered in class. Therefore, please regard sections 4 and onward as "supplementary". Sections 1-3 remain part of the core syllabus. -John Heidemann From coolrocks at tom.com Thu Apr 29 20:21:17 2004 From: coolrocks at tom.com (Coolrocks) Date: Thu Apr 29 20:51:50 2004 Subject: [Csci551-talk] Packet count Message-ID: <00ad01c42e62$362e8e70$6500a8c0@coolrocks> Hi, Went through the updated specs, still have a doubt: Does a packet that is originated and received by the same router also count as a "received packet"? Or only a packet that is originated by some other router count as a "received packet"? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20040429/be45fe72/attachment.html From johnh at ISI.EDU Fri Apr 30 08:35:36 2004 From: johnh at ISI.EDU (John Heidemann) Date: Fri Apr 30 08:38:03 2004 Subject: [Csci551-talk] bug fix for sample code input file handling Message-ID: <200404301535.i3UFZbQS000661@dash.isi.edu> A student previously posted on the list that the sample code's handling of input files didn't match the project specification---the sample code reads from an input file explicitly, not from stdin. In my initial response I suggested that the code handled either case, but this statement was incorrect. A patch and/or replacement to main.cc should fix this problem, allowing the sample code to read from stdin by default if no command-line arguments are given. Since this IS how we will run tests on the program, you should apply this patch to your code if you're using the sample code in your project B. (We will NOT read inputs from config.conf when testing Proj B code!) -John Heidemann -------------- next part -------------- A non-text attachment was scrubbed... Name: input_handling.patch Type: application/octet-stream Size: 802 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/csci551-talk/attachments/20040430/70996702/input_handling.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cc Type: application/octet-stream Size: 1762 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/csci551-talk/attachments/20040430/70996702/main.obj From coolrocks at tom.com Fri Apr 30 22:21:20 2004 From: coolrocks at tom.com (Coolrocks) Date: Fri Apr 30 22:23:42 2004 Subject: [Csci551-talk] Project B submition question Message-ID: <005901c42f3c$272a66d0$6500a8c0@coolrocks> Hi, I am using the provided solution code for project A. When submitting project B, how do I submit the timer code? The makefile in the provided solution goes to the "timer directory" for compilation of the timer code, but "submit" command doesn't support submitting whole directories. So shall I merge the timer code into the same directory as the other files and make changes to the "makefile" or else? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/csci551-talk/attachments/20040430/a3707338/attachment.html