From detlef.bosau at web.de Wed Feb 1 03:03:00 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 01 Feb 2006 12:03:00 +0100 Subject: [e2e] Redirection-Based Flooding Attacks (was Re: DDoS attackvs.Spoofing of Source Address) References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43DE8C2E.4090805@tm.uka.de> <43DF718A.47CD28D0@web.de> <43E05E4C.1080806@tm.uka.de> Message-ID: <43E09564.8A23696E@web.de> Christian Vogt wrote: > > Detlef, > > the attacker would have to send TCP acknowledgments in order to make > the TCP sender assume that the packets go to the right IP address. If > the mobility protocol allows only for a single address' registration, > the TCP acknowledgments have to be spoofed. > This is what you wrote. The attacker behaves like a TCP receiver. My question is: What happens when the attacker redirects the flow to the victim? Does the attacker continue to spoof ACK packets then? If so, this could be perhaps a rather inefficient way for an attack because the attacker must continue to spoof ACK packets all the time. So, the motiviation for doing so would be for the attacker to hide its identity from both the victim and the sender and have the DoS flow appear like an ordinary TCP flow from the (abused) sender. Is this correct? In fact, I didn?t see this kind of motivation yesterday. -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From chvogt at tm.uka.de Wed Feb 1 03:47:02 2006 From: chvogt at tm.uka.de (Christian Vogt) Date: Wed, 01 Feb 2006 12:47:02 +0100 Subject: [e2e] Redirection-Based Flooding Attacks (was Re: DDoS attack vs. Spoofing of Source Address) In-Reply-To: <43E09564.8A23696E@web.de> References: <20060118162500.10B6D136C82@aharp.ittns.northwestern.edu> <43DE8C2E.4090805@tm.uka.de> <43DF718A.47CD28D0@web.de> <43E05E4C.1080806@tm.uka.de> <43E09564.8A23696E@web.de> Message-ID: <43E09FB6.20700@tm.uka.de> > This is what you wrote. The attacker behaves like a TCP receiver. My > question is: What happens when the attacker redirects the flow to the > victim? Does the attacker continue to spoof ACK packets then? It begins spoofing ACK packets then. Of course, it can send correct ACK packets before the redirection. > If so, > this could be perhaps a rather inefficient way for an attack because > the attacker must continue to spoof ACK packets all the time. So, the > motiviation for doing so would be for the attacker to hide its > identity from both the victim and the sender and have the DoS flow > appear like an ordinary TCP flow from the (abused) sender. Is this > correct? In fact, I didn?t see this kind of motivation yesterday. The motivation is about amplification: The attacker can sent one small ACK packet for each two (usually full-sized) segments that the TCP sender generates. - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ Detlef Bosau wrote: > Christian Vogt wrote: > >> Detlef, >> >> the attacker would have to send TCP acknowledgments in order to >> make the TCP sender assume that the packets go to the right IP >> address. If the mobility protocol allows only for a single >> address' registration, the TCP acknowledgments have to be spoofed. > > > This is what you wrote. The attacker behaves like a TCP receiver. My > question is: What happens when the attacker redirects the flow to the > victim? Does the attacker continue to spoof ACK packets then? If so, > this could be perhaps a rather inefficient way for an attack because > the attacker must continue to spoof ACK packets all the time. So, the > motiviation for doing so would be for the attacker to hide its > identity from both the victim and the sender and have the DoS flow > appear like an ordinary TCP flow from the (abused) sender. Is this > correct? In fact, I didn?t see this kind of motivation yesterday. From rewaskar at email.unc.edu Wed Feb 1 15:46:21 2006 From: rewaskar at email.unc.edu (Sushant Rewaskar) Date: Wed, 1 Feb 2006 18:46:21 -0500 Subject: [e2e] Estimating MS windows RTO equation Message-ID: <000001c62789$b47cfa10$7a850298@cs.unc.edu> Hi, My name is Sushant Rewaskar. I am a graduate student at UNC Chapel Hill. I have been looking at how the windows OS estimated the RTO (Retransmission Time Out) but looks like it is not such a simple problem. I ran a series of experiments with constant RTT as well as with variable RTT to try and figure out what equations (of the form RTO_timer = a *srtt + B *rttvar) does windows use. Turns out, the equation is not that simple. Add to this the unknown clock granularity and this becomes a touch problem. I am seeking information or/and ideas as to how one can estimate the equation(s) used by windows. Below are details of how we approached this problem. To create a controlled environment we set up two machines in the lab. One of the test machines was windows (with XP pro) and the other was a FreeBSD machine. We used tbit [http://www.icir.org/tbit/] to request a webpage from the windows machine. We allowed the connection to transfer 250 packets (allowing the connection to enter congestion avoidance and allow the RTO estimator equation to converge). The above experiments were first run with a constant RTT. (We varied the values from 50, 100, 150, 200, 400, 750, 1000, 1200, 1400 ms). Under the constant RTT situation the rttvar should be reduced to a very low value. In this case the RTO estimator should be a direct function of srtt and maybe a constant. The empirically derived RTO value would be affected by the clock granularity of the system. For e.g. if the clock granularity is 100ms. The actual time when the RTO timer is triggered can be offset by 100ms on either side of the actual time. To take care of this we ran the tbit experiment 1000 times for each of the 9 RTT values and took the median as the probable RTO value for that RTT. For constant RTT we assumed that the RTO estimation equation was of the form. RTO = a*srtt + C. I used a matlab linear equation solver to estimate the constants a and C. the results I got varied with the experiments and did not appear intuitively (got constants like 2.7 for "a" and similar non integer for "C") We repeated these experiments with variable RTT (the same base values as above with a 25% random change in the RTT). We hoped to have obtained "a" from above and then estimate "b" for the following RTO equation (RTO = a * srtt + b rttvar). Anyway, any ideas are welcome. Take care, Sushant Rewaskar UNC Chapel Hill www.cs.unc.edu/~rewaskar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060201/ce0cdba2/attachment.html From detlef.bosau at web.de Thu Feb 2 03:31:03 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 02 Feb 2006 12:31:03 +0100 Subject: [e2e] Estimating MS windows RTO equation References: <000001c62789$b47cfa10$7a850298@cs.unc.edu> Message-ID: <43E1ED77.F6958110@web.de> Hm. First of all, its interesting why you are interested in just MS Windows? RTO esitmator ;-) Basically, MS is free to implement anything they like as long as their OS are well behaved, i.e. do not cause trouble to other network participants. Of course, it might be a good idea to follow the actual RFC ;-) To your problem. How did you obtain the rtxtimer samples from which you try to estimate your parameters? Presumably, you did not take them from the OS kernel code, because if that were available for you you could easily look up the RTO equation from that ;-) -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From rewaskar at email.unc.edu Thu Feb 2 05:26:37 2006 From: rewaskar at email.unc.edu (Sushant Rewaskar) Date: Thu, 2 Feb 2006 08:26:37 -0500 Subject: [e2e] Estimating MS windows RTO equation In-Reply-To: <43E1ED77.F6958110@web.de> Message-ID: <004801c627fc$4bd28ed0$7a850298@cs.unc.edu> Hi, It is not that we are interested in only MS windows machines; however, it is the only one which we have not figured out yet. We have created a partial state machine based tool for tracing the state of the TCP connections. This helps us identify the cause of retransmission of a packet and by using extra logic we can identify other things like whether the packet was needed or not. Now the problem with creating a general partial state-machine is that there is a lot of variation in the way TCP is implemented in the different OSes (windows for e.g. enters fast retransmit after 2 dupack instead of 3 as suggested in the RFC). There are many other differences across the different OSes especially in the way the RTO is estimated. We are trying to determine the RTO equations so that we can (i) exactly tell which packet is triggered by a timeout and (2) if we get a very good match between the observed retransmission time and calculated RTO, we would also be able to tell that the particular connection below to a particular OS. We have been able to build almost perfect state machines for Linux, Solaris and FreeBSD (MacOS) and have been able to do a decent job for windows (including identifying certain unusual behavior which is peculiar to windows OSes). However, we are still struggling to get the RTO estimation perfected. Details about the tool are available in the following tech report http://www.cs.unc.edu/~rewaskar/publication/TR06-002.pdf About the RTT calculation. For the experiments I mentioned in the last mail we are collecting a tcpdump at the sender (FreeBSD machine) and calculate RTT using karls Algorithm. The details for RTT estimation are in the following paper http://www.cs.unc.edu/~jasleen/papers/imc03.pdf Thank you, Sushant Rewaskar ----------------------------- UNC Chapel Hill www.cs.unc.edu/~rewaskar -----Original Message----- From: detlef.bosau at web.de [mailto:detlef.bosau at web.de] Sent: Thursday, February 02, 2006 6:31 AM To: rewaskar at cs.unc.edu Cc: end2end-interest at postel.org Subject: Re: [e2e] Estimating MS windows RTO equation Hm. First of all, its interesting why you are interested in just MS Windows? RTO esitmator ;-) Basically, MS is free to implement anything they like as long as their OS are well behaved, i.e. do not cause trouble to other network participants. Of course, it might be a good idea to follow the actual RFC ;-) To your problem. How did you obtain the rtxtimer samples from which you try to estimate your parameters? Presumably, you did not take them from the OS kernel code, because if that were available for you you could easily look up the RTO equation from that ;-) -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From spencer at mcsr-labs.org Thu Feb 2 05:56:27 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Thu, 2 Feb 2006 08:56:27 -0500 Subject: [e2e] Estimating MS windows RTO equation References: <004801c627fc$4bd28ed0$7a850298@cs.unc.edu> Message-ID: <03f901c62801$05c913a0$6b01a8c0@china.huawei.com> (Sigh)... > Now the problem with creating a general partial state-machine is that > there > is a lot of variation in the way TCP is implemented in the different OSes > (windows for e.g. enters fast retransmit after 2 dupack instead of 3 as > suggested in the RFC). There are many other differences across the > different > OSes especially in the way the RTO is estimated. I really liked the fact that we had TCPIMPL, and wish we still did. I happened to see a "what's exponential backoff?" packet trace from a GPRS handset about a year ago, but there's no place to catalog this stuff any more... http://www.ietf.org/html.charters/OLD/tcpimpl-charter.html Spencer From mellia at tlc.polito.it Thu Feb 2 06:38:31 2006 From: mellia at tlc.polito.it (Marco Mellia) Date: 02 Feb 2006 15:38:31 +0100 Subject: [e2e] Estimating MS windows RTO equation In-Reply-To: <004801c627fc$4bd28ed0$7a850298@cs.unc.edu> References: <004801c627fc$4bd28ed0$7a850298@cs.unc.edu> Message-ID: <1138891111.22474.16.camel@mellia.lipar.polito.it> We are working on the same topic, identifying packet anomalies (e.g. retransmissions) in a TCP flow from passive measurement. If you are interested, here are the links on the papers that we'll be presented in June at ICC M.Mellia, M.Meo, L.Muscariello, D.Rossi, "Passive Identification and Analysis of TCP Anomalies", IEEE ICC'06, Istanbul, Turkey, 11-15 June 2006 http://www.tlc-networks.polito.it/mellia/papers/icc06_passive.pdf The tool we are using which implements all the code is available as well from http://tstat.tlc.polito.it Hope this helps. > Hi, > It is not that we are interested in only MS windows machines; however, it is > the only one which we have not figured out yet. > > We have created a partial state machine based tool for tracing the state of > the TCP connections. This helps us identify the cause of retransmission of a > packet and by using extra logic we can identify other things like whether > the packet was needed or not. > > Now the problem with creating a general partial state-machine is that there > is a lot of variation in the way TCP is implemented in the different OSes > (windows for e.g. enters fast retransmit after 2 dupack instead of 3 as > suggested in the RFC). There are many other differences across the different > OSes especially in the way the RTO is estimated. We are trying to determine > the RTO equations so that we can (i) exactly tell which packet is triggered > by a timeout and (2) if we get a very good match between the observed > retransmission time and calculated RTO, we would also be able to tell that > the particular connection below to a particular OS. We have been able to > build almost perfect state machines for Linux, Solaris and FreeBSD (MacOS) > and have been able to do a decent job for windows (including identifying > certain unusual behavior which is peculiar to windows OSes). However, we are > still struggling to get the RTO estimation perfected. Details about the > tool are available in the following tech report > http://www.cs.unc.edu/~rewaskar/publication/TR06-002.pdf > > About the RTT calculation. For the experiments I mentioned in the last mail > we are collecting a tcpdump at the sender (FreeBSD machine) and calculate > RTT using karls Algorithm. The details for RTT estimation are in the > following paper http://www.cs.unc.edu/~jasleen/papers/imc03.pdf > > Thank you, > Sushant Rewaskar > ----------------------------- > UNC Chapel Hill > www.cs.unc.edu/~rewaskar > > > -----Original Message----- > From: detlef.bosau at web.de [mailto:detlef.bosau at web.de] > Sent: Thursday, February 02, 2006 6:31 AM > To: rewaskar at cs.unc.edu > Cc: end2end-interest at postel.org > Subject: Re: [e2e] Estimating MS windows RTO equation > > Hm. > > First of all, its interesting why you are interested in just MS Windows? > RTO esitmator ;-) > Basically, MS is free to implement anything they like as long as their > OS are well behaved, i.e. do not cause trouble to other network > participants. > Of course, it might be a good idea to follow the actual RFC ;-) > > To your problem. > > How did you obtain the rtxtimer samples from which you try to estimate > your parameters? > > Presumably, you did not take them from the OS kernel code, because if > that were available for you you could easily look up the RTO equation > from > that ;-) -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Tel: 39-011-2276-608 | | Tel: 39-011-564-4173 | | Cel: 39-340-9674888 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www1.tlc.polito.it/mellia | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. From detlef.bosau at web.de Thu Feb 2 08:23:03 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 02 Feb 2006 17:23:03 +0100 Subject: [e2e] Estimating MS windows RTO equation References: <004801c627fc$4bd28ed0$7a850298@cs.unc.edu> <1138891111.22474.16.camel@mellia.lipar.polito.it> Message-ID: <43E231E7.6DF5887A@web.de> Marco Mellia wrote: > > We are working on the same topic, identifying packet anomalies (e.g. > retransmissions) in a TCP flow from passive measurement. > If you are interested, here are the links on the papers that we'll be > presented in June at ICC It would be interesting to see whether you will create a trace "what are spurious timeouts" in GPRS ;-) *SCNR* To be serious: It would not be interesting to understand, what an SRTO really _is_, but it would be helpful to see, whether those practically occur. If you look at the technical report "TCP Spurious Timeout estimation in an operational GPRS/UMTS network" by Francesco Vacirca, Thomas Ziegler and Eduard Hasenleithner, the authors do passive measurements of the particular anomalie "spurious timeout" and end up in the observation that these do hardly occur in reality. If this is correct, particularly the importance of SRTO has been drastically overestimated during the past few years. So, what I think would be particularly interesting in a work like yours is that we are able to discrimate important problems from non important / neglectible ones. It?s perhaps not that important to have an "OS identifying mechanism". IIRC there are quite a few papers around on this matter and to my understanding, this is more some kind of (necessary! and sophisticated!) debugging than "pure science". However, it is very important to find out whether e.g. SRTO are reality or not. Spoken more drastically: If someone rides the SRTO horse once again, does he ride a dead horse? This question is somewhat off topic for this thread, however I?m very interested in this topic. BTW: My personal expectation is that SRTO _ARE_ a dead horse. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From mellia at tlc.polito.it Thu Feb 2 08:41:25 2006 From: mellia at tlc.polito.it (Marco Mellia) Date: 02 Feb 2006 17:41:25 +0100 Subject: [e2e] Estimating MS windows RTO equation In-Reply-To: <43E231E7.6DF5887A@web.de> References: <004801c627fc$4bd28ed0$7a850298@cs.unc.edu> <1138891111.22474.16.camel@mellia.lipar.polito.it> <43E231E7.6DF5887A@web.de> Message-ID: <1138898485.23007.3.camel@mellia.lipar.polito.it> We are actually discriminating between - needed retransmission due to RTO - unneeded retrasmission due to RTO (e.g., retransmitted packets already acked by the client). The second case may happen due to (but not only) spurious timeout expiration. What is interesting is that unneeded retransmission almost "disappear" if SACK is being used, hinting that they are more related to "wrong" selective retransmit behavior rathern then wrong RTO estimation... If you want, you can read that as "spurios rto firing" is a very rare event... > Marco Mellia wrote: > > > > We are working on the same topic, identifying packet anomalies (e.g. > > retransmissions) in a TCP flow from passive measurement. > > If you are interested, here are the links on the papers that we'll be > > presented in June at ICC > > > It would be interesting to see whether you will create a trace "what are > spurious timeouts" in GPRS ;-) *SCNR* > > To be serious: It would not be interesting to understand, what an SRTO > really _is_, but it would be helpful to see, whether those practically > occur. > If you look at the technical report "TCP Spurious Timeout estimation in > an operational GPRS/UMTS network" by > Francesco Vacirca, Thomas Ziegler and Eduard Hasenleithner, the authors > do passive measurements of the particular anomalie "spurious timeout" > and end up in the observation that these do hardly occur in reality. If > this is correct, particularly the importance of SRTO > has been drastically overestimated during the past few years. > > So, what I think would be particularly interesting in a work like yours > is that we are able to discrimate important problems from > non important / neglectible ones. > > It?s perhaps not that important to have an "OS identifying mechanism". > IIRC there are quite a few papers around on this matter > and to my understanding, this is more some kind of (necessary! and > sophisticated!) debugging than "pure science". > > However, it is very important to find out whether e.g. SRTO are reality > or not. Spoken more drastically: If someone rides > the SRTO horse once again, does he ride a dead horse? > > This question is somewhat off topic for this thread, however I?m very > interested in this topic. BTW: My personal expectation > is that SRTO _ARE_ a dead horse. > > Detlef -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Tel: 39-011-2276-608 | | Tel: 39-011-564-4173 | | Cel: 39-340-9674888 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www1.tlc.polito.it/mellia | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. From francesco at net.infocom.uniroma1.it Thu Feb 2 11:03:21 2006 From: francesco at net.infocom.uniroma1.it (francesco@net.infocom.uniroma1.it) Date: Thu, 2 Feb 2006 20:03:21 +0100 Subject: [e2e] Estimating MS windows RTO equation In-Reply-To: <43E231E7.6DF5887A@web.de> References: <004801c627fc$4bd28ed0$7a850298@cs.unc.edu> <1138891111.22474.16.camel@mellia.lipar.polito.it> <43E231E7.6DF5887A@web.de> Message-ID: <1138907001.43e257799b5db@net.infocom.uniroma1.it> Quoting Detlef Bosau : > Marco Mellia wrote: > > > > We are working on the same topic, identifying packet anomalies (e.g. > > retransmissions) in a TCP flow from passive measurement. > > If you are interested, here are the links on the papers that we'll be > > presented in June at ICC > > > It would be interesting to see whether you will create a trace "what are > spurious timeouts" in GPRS ;-) *SCNR* > > To be serious: It would not be interesting to understand, what an SRTO > really _is_, but it would be helpful to see, whether those practically > occur. > If you look at the technical report "TCP Spurious Timeout estimation in > an operational GPRS/UMTS network" by > Francesco Vacirca, Thomas Ziegler and Eduard Hasenleithner, the authors > do passive measurements of the particular anomalie "spurious timeout" > and end up in the observation that these do hardly occur in reality. If > this is correct, particularly the importance of SRTO > has been drastically overestimated during the past few years. > Our results cannot be considered as general but refer to the monitored UMTS/GPRS network. It would be interesting to see other results from different networks... The details about the algorithm for the SRTO estimation and the results for the monitored network can be found here: http://userver.ftw.at/~ziegler/FTW-TR-2005-008.pdf whereas the patch for tcptrace with the algorithm can be downloaded from: http://userver.ftw.at/~vacirca/ Francesco > So, what I think would be particularly interesting in a work like yours > is that we are able to discrimate important problems from > non important / neglectible ones. > > It?s perhaps not that important to have an "OS identifying mechanism". > IIRC there are quite a few papers around on this matter > and to my understanding, this is more some kind of (necessary! and > sophisticated!) debugging than "pure science". > > However, it is very important to find out whether e.g. SRTO are reality > or not. Spoken more drastically: If someone rides > the SRTO horse once again, does he ride a dead horse? > > This question is somewhat off topic for this thread, however I?m very > interested in this topic. BTW: My personal expectation > is that SRTO _ARE_ a dead horse. > > Detlef > > -- > Detlef Bosau > Galileistrasse 30 > 70565 Stuttgart > Mail: detlef.bosau at web.de > Web: http://www.detlef-bosau.de > Mobile: +49 172 681 9937 > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From detlef.bosau at web.de Thu Feb 2 12:53:09 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 02 Feb 2006 21:53:09 +0100 Subject: [e2e] Estimating MS windows RTO equation References: <004801c627fc$4bd28ed0$7a850298@cs.unc.edu> <1138891111.22474.16.camel@mellia.lipar.polito.it> <43E231E7.6DF5887A@web.de> <1138907001.43e257799b5db@net.infocom.uniroma1.it> Message-ID: <43E27135.6D0312C5@web.de> francesco at net.infocom.uniroma1.it wrote: > > Our results cannot be considered as general but refer to the monitored UMTS/GPRS > network. It would be interesting to see other results from different > networks... This would be interesting in fact. However, as I already wrote to Thomas Ziegler as a PM, I would hardly expect similar results there. It would be particularly interesting to change the wireless/mobility conditions with those experiments. I think, the applications will not really matter. The interesting question is: Will a change in the wireless condition result in "delay spikes" or abrupt delay changes that can cause spurious timeouts? I don?t really expect this. When I want to produce SRTO in simulations, I must introduce extremely hard and abrupt latency changes into the path. And even if the BER of a wireless channel (refer to http://www.detlef-bosau.de/layers.html) suffers from abrupt changes, causing abrubt changes in the BLER, one single TCP or UDP packet usually consists of serveral "radio blocks", thus the transport latency for a whole UDP or TCP packet is the sum from a number of, roughly spoken, geometrically distributed random numbers. In consequence, even an abrupt change in the wireless condition does not result in an abrubt change in the transport latencies but only the expectian and variation of this latency changes. The latencies themselves are still "sufficiently smooth" so that a sender?s rxmittimer can "follow" them or, in case of large variation, is sufficiently large. That?s what I conclude from my "home made" model - and your observations confirm this. Basically, the "big picture" of this is an old question of mine: "Adverse interactions between L4 and L2, are they myth or reality?" I know there is quite a lot of work around concerning this topic. But I must admit: I?m absolutely not convinced of this. As I have written to Thomas Ziegler, I?m still not convinced that there at least _exist_ any particular interactions between mobile wireless networks and TCP which require structural changes to TCP. If you asked me for this a year ago, I would have given a completely different answer. But as you wrote in your paper, it is at least questionable that TCP must be changed in order to be used with wireless networks. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Thu Feb 2 13:18:00 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 02 Feb 2006 22:18:00 +0100 Subject: [e2e] Estimating MS windows RTO equation References: <004801c627fc$4bd28ed0$7a850298@cs.unc.edu> <1138891111.22474.16.camel@mellia.lipar.polito.it> <43E231E7.6DF5887A@web.de> <1138898485.23007.3.camel@mellia.lipar.polito.it> Message-ID: <43E27708.8715D71@web.de> Marco Mellia wrote: > > We are actually discriminating between > - needed retransmission due to RTO > - unneeded retrasmission due to RTO (e.g., retransmitted packets already > acked by the client). > The second case may happen due to (but not only) spurious timeout > expiration. What is interesting is that unneeded retransmission almost > "disappear" if SACK is being used, hinting that they are more related to > "wrong" selective retransmit behavior rathern then wrong RTO > estimation... > If you want, you can read that as "spurios rto firing" is a very rare > event... > >From what I understood so far, refer to e.g. RFC 3517, one of the main objectives for the use of SACK is loss detection. And there exist elaborate mechanisms for the propper setting of the dupackthreshold used in actual TCP implementations (as a replacement for the rather inflexible "3"). In addition, when we recall Edge?s paper, the central idea for the constrution of an rxmit-Timer is to build an estimate for a RTT confidence interval. The basic idea behind this is Chebyshev?s inequality, therefore the approach is as generic as it could be.... So, it would be extremely surprising, when some particular network?s SRTO rate would exceed the accepted level, which is in fact quite high. When I played around a bit with Edge?s formulae, I ended up in an accptable SRTO rate of less then 1/5 for "E + 2*V" and 1/17 for "E + 2*V". And this is about two orders of magnitude higher than the values observed by Vacirca, Ziegler and Hasenleithner. So, your observed behaviour, particularly the effect of a proper use of SACK, exactly matches the expected behaviour. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From saurin.shah at gmail.com Thu Feb 2 14:15:18 2006 From: saurin.shah at gmail.com (Saurin Shah) Date: Thu, 2 Feb 2006 16:15:18 -0600 Subject: [e2e] Narada Simulation Message-ID: <98ef8a0b0602021415m535be77ated5c05b9391d58b5@mail.gmail.com> Hi, I am working on a project, and I am trying to perform a simulation of the Narada Protocol. Is there any simulator available, or if there isn't, then can anyone throw some light on how to implement it ? Any advice or comments will be of great help. Thanks Regards Saurin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060202/0b59b34d/attachment.html From doug at eee.strath.ac.uk Thu Feb 2 17:16:47 2006 From: doug at eee.strath.ac.uk (Douglas Leith) Date: Fri, 3 Feb 2006 01:16:47 -0000 Subject: [e2e] FW: Performance evaluation of high speed TCPs References: Message-ID: Injong, Re your recent report, could you just confirm that the htcp results should be disregarded (I think updated results are on the web now though) as they reflect a bug in the linux htcp implementation rather than correct performance ? Thanks. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060203/370ad5c0/attachment.html From doug at eee.strath.ac.uk Thu Feb 2 18:24:33 2006 From: doug at eee.strath.ac.uk (Douglas Leith) Date: Fri, 3 Feb 2006 02:24:33 -0000 Subject: [e2e] FW: Performance evaluation of high speed TCPs References: <39307.60.44.142.168.1138932213.squirrel@webmail.ncsu.edu> Message-ID: >Seriously, we can't run the tests for every fix and bug report. Perhaps best to view it as returning a favour. You may recall that we re-ran all our own experimental tests last year (all data and code available online at www.hamilton.ie/net/eval/) on discovering a previously unreported bug introduced by the linux folks when implementing bic. Something similar has happened with importing htcp into linux. Seriously, where's the value in comparing buggy implementations - isn't that just a waste of all our time ? If we are genuine about wanting to understand tcp performance then I think we just have to take the hit from issues such as this that are outside all of our control. Doug Hamilton Institute www.hamilton.ie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060203/8e20dfaa/attachment.html From rhee at ncsu.edu Thu Feb 2 18:29:07 2006 From: rhee at ncsu.edu (rhee@ncsu.edu) Date: Thu, 2 Feb 2006 21:29:07 -0500 (EST) Subject: [e2e] FW: Performance evaluation of high speed TCPs In-Reply-To: References: Message-ID: <44849.60.44.142.168.1138933747.squirrel@webmail.ncsu.edu> Doug, The new bug patch was announced last week. Unfortunately we are not THAT real time in updating the report :-) Seriously, we can't run the tests for every fix and bug report. But we are aware of your new patch posted last week on the e2e list and indeed applied it to our testing platform for retesting.Now one test case is done (thanks to Sangtae who spent a few sleepless nights to set up and re-run the tests). These tests take time to rerun and they are still going on and when they are done, we will update the document. At this point, i can confirm at least that HTCP performance looks a LOT improved, but we still found a few new issues even with the updated HTCP -- in the same performance areas that we pointed out in the document, such as utilization and stability. We are looking to find out whether these issues are caused by side-effects of our setup or by the HTCP algorithm itself. As soon as we get some more confirmation on our findings we will update the report. Please bear with us on this and stay tuned. I hope our report and testing help the community in studying and improving TCP performance. Regards, Injong Injong Rhee, Department of Computer Science North Carolina State University, Raleigh, NC 27695 Home page: http://www.csc.ncsu.edu/faculty/rhee Email: rhee at csc.ncsu.edu, Phone: 919-515-3305, Fax: 919-515-7925 > Injong, > > Re your recent report, could you just confirm that the htcp results should > be disregarded (I think updated results are on the web now though) as they > reflect a bug in the linux htcp implementation rather than correct > performance ? Thanks. > > Doug > > From rhee at ncsu.edu Thu Feb 2 18:50:07 2006 From: rhee at ncsu.edu (rhee@ncsu.edu) Date: Thu, 2 Feb 2006 21:50:07 -0500 (EST) Subject: [e2e] FW: Performance evaluation of high speed TCPs In-Reply-To: References: <39307.60.44.142.168.1138932213.squirrel@webmail.ncsu.edu> Message-ID: <48677.60.44.142.168.1138935007.squirrel@webmail.ncsu.edu> Sure. Your comments about running the buggy implementation are well taken. That is why this type of reporting is helpful and we are committed to keep this effort. Just that it takes time to run the tests, and before we run a new set of tests, we have to do some batch of patches to reduce our effort level (but in this case of the HTCP bug, rest assured that we are running it now..it is just that there are a lot of other things going on that we have to catch a breath a little). Then again, if we don't do the test and keep the report up-to-date then it is difficult to find bugs as well...so these reportings help us find bugs and also improve TCP algorithms. (I hope our report did the same for you). Also sometimes we are not motivated to find the bugs ourselves. In fact, i contacted your student "Baruch" one month and half before we posted our report -- it was CCed in the netdev mailing list as well and we gave him login and passwd on our result website (at that time we were just about to write the report) and we have not heard from your guys until just one week ago. At least we did try to make sure we are running a buggy version. >>Seriously, we can't run the tests for every fix and bug report. > > Perhaps best to view it as returning a favour. You may recall that we > re-ran all our own experimental tests last year (all data and code > available online at www.hamilton.ie/net/eval/) on discovering a previously > unreported bug introduced by the linux folks when implementing bic. > Something similar has happened with importing htcp into linux. > > Seriously, where's the value in comparing buggy implementations - isn't > that just a waste of all our time ? If we are genuine about wanting to > understand tcp performance then I think we just have to take the hit from > issues such as this that are outside all of our control. > > Doug > > Hamilton Institute > www.hamilton.ie > From skaniyar at hotmail.com Thu Feb 2 21:39:55 2006 From: skaniyar at hotmail.com (sanjay kaniyar) Date: Thu, 02 Feb 2006 21:39:55 -0800 Subject: [e2e] Estimating MS windows RTO equation In-Reply-To: <004801c627fc$4bd28ed0$7a850298@cs.unc.edu> Message-ID: Sushant - Windows uses the very same algorithms prescribed by the standard RFCs - so, I would think you should see the results you are expecting... if you are not, send a mail just to me and we will work with you. And yes, Windows does fast-retransmission upon receiving 2nd dup ACK. Thanks, Sanjay kaniyar (Windows networking, Microsoft) >From: "Sushant Rewaskar" >Reply-To: rewaskar at cs.unc.edu >To: >CC: end2end-interest at postel.org >Subject: Re: [e2e] Estimating MS windows RTO equation >Date: Thu, 2 Feb 2006 08:26:37 -0500 > >Hi, >It is not that we are interested in only MS windows machines; however, it >is >the only one which we have not figured out yet. > >We have created a partial state machine based tool for tracing the state of >the TCP connections. This helps us identify the cause of retransmission of >a >packet and by using extra logic we can identify other things like whether >the packet was needed or not. > >Now the problem with creating a general partial state-machine is that there >is a lot of variation in the way TCP is implemented in the different OSes >(windows for e.g. enters fast retransmit after 2 dupack instead of 3 as >suggested in the RFC). There are many other differences across the >different >OSes especially in the way the RTO is estimated. We are trying to determine >the RTO equations so that we can (i) exactly tell which packet is triggered >by a timeout and (2) if we get a very good match between the observed >retransmission time and calculated RTO, we would also be able to tell that >the particular connection below to a particular OS. We have been able to >build almost perfect state machines for Linux, Solaris and FreeBSD (MacOS) >and have been able to do a decent job for windows (including identifying >certain unusual behavior which is peculiar to windows OSes). However, we >are >still struggling to get the RTO estimation perfected. Details about the >tool are available in the following tech report >http://www.cs.unc.edu/~rewaskar/publication/TR06-002.pdf > >About the RTT calculation. For the experiments I mentioned in the last mail >we are collecting a tcpdump at the sender (FreeBSD machine) and calculate >RTT using karls Algorithm. The details for RTT estimation are in the >following paper http://www.cs.unc.edu/~jasleen/papers/imc03.pdf > >Thank you, >Sushant Rewaskar >----------------------------- >UNC Chapel Hill >www.cs.unc.edu/~rewaskar > > >-----Original Message----- >From: detlef.bosau at web.de [mailto:detlef.bosau at web.de] >Sent: Thursday, February 02, 2006 6:31 AM >To: rewaskar at cs.unc.edu >Cc: end2end-interest at postel.org >Subject: Re: [e2e] Estimating MS windows RTO equation > >Hm. > >First of all, its interesting why you are interested in just MS Windows´ >RTO esitmator ;-) >Basically, MS is free to implement anything they like as long as their >OS are well behaved, i.e. do not cause trouble to other network >participants. >Of course, it might be a good idea to follow the actual RFC ;-) > >To your problem. > >How did you obtain the rtxtimer samples from which you try to estimate >your parameters? > >Presumably, you did not take them from the OS kernel code, because if >that were available for you you could easily look up the RTO equation >from >that ;-) > > >-- >Detlef Bosau >Galileistrasse 30 >70565 Stuttgart >Mail: detlef.bosau at web.de >Web: http://www.detlef-bosau.de >Mobile: +49 172 681 9937 > From detlef.bosau at web.de Fri Feb 3 03:50:27 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 03 Feb 2006 12:50:27 +0100 Subject: [e2e] Estimating MS windows RTO equation References: Message-ID: <43E34383.CF211E7@web.de> sanjay kaniyar wrote: > > Sushant - > > Windows uses the very same algorithms prescribed by the standard RFCs - so, Sounds interesting :-) I did not look at the code, but some few years ago the tabloids here in Germany talked about some "proprietary TCP/IP extensions" implemented by Microsoft. I did not check this myself, I even did not have any opportunity for doing so. However, after reading this rumour I?m somewhat suspicious about Windows. It might be a personal problem of mine. Anyway. Saying, an implementation uses the very same algoriths prescribed by the standard RFCs sounds not very sound ;-) There are dozens of papers around which find flaws in comon TCP implementations (and I vaguely remember at least one which did not only discovered flaws in HP UX and Solaris but in Windows NT as well) and even in this thread here we talked about a project which dealt with implementation flaws in actual TCP implemenations. Perhaps the most funny thing in this context is a switch I found in Linux with which the Linux TCP implementation can be made "bug to bug compatible" with BSD :-) > I would think you should see the results you are expecting... if you are > not, send a mail just to me and we will work with you. > > And yes, Windows does fast-retransmission upon receiving 2nd dup ACK. So, we have the first implementation flaw in Windows TCP, haven?t we? (Assuemd, "3rd" dup ACK is correct, I didn?t look it up myself, because neither is state of the art. State of the art is the use of a user / application defined dupackthreshold. -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From doug at eee.strath.ac.uk Fri Feb 3 06:06:15 2006 From: doug at eee.strath.ac.uk (Douglas Leith) Date: Fri, 3 Feb 2006 14:06:15 -0000 Subject: [e2e] FW: Performance evaluation of high speed TCPs References: <39307.60.44.142.168.1138932213.squirrel@webmail.ncsu.edu> <48677.60.44.142.168.1138935007.squirrel@webmail.ncsu.edu> Message-ID: Injong, >In fact, i contacted your student "Baruch" one month and half before we posted our report -- it was CCed in the netdev mailing list as well and we gave him login and passwd on our result website (at that time we were just about to write the report) and we have not heard from your guys until just one week ago. At least we did try to make sure we are running a buggy version. We have no record of receiving such an email. Just a mix-up I guess. Doug >>Seriously, we can't run the tests for every fix and bug report. > > Perhaps best to view it as returning a favour. You may recall that we > re-ran all our own experimental tests last year (all data and code > available online at www.hamilton.ie/net/eval/) on discovering a previously > unreported bug introduced by the linux folks when implementing bic. > Something similar has happened with importing htcp into linux. > > Seriously, where's the value in comparing buggy implementations - isn't > that just a waste of all our time ? If we are genuine about wanting to > understand tcp performance then I think we just have to take the hit from > issues such as this that are outside all of our control. > > Doug > > Hamilton Institute > www.hamilton.ie > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060203/9a5af9a5/attachment.html From feamster at cc.gatech.edu Thu Feb 2 12:53:58 2006 From: feamster at cc.gatech.edu (Nick Feamster) Date: Thu, 2 Feb 2006 15:53:58 -0500 Subject: [e2e] CFP: Workshop on the Economics of Networked Systems (NetEcon) 2006 Message-ID: <20060202205358.GA10496@cc.gatech.edu> Call For Papers Workshop on the Economics of Networked Systems (NetEcon) June 11, 2006 Ann Arbor, Michigan NetEcon merges two workshops held in previous years: P2PEcon (Economics of Peer-to-Peer Systems) and PINS (Practice and Theory of Incentives in Networked Systems). The goal of the workshop is to promote a cross-disciplinary exchange of ideas on the role of game-theoretic and economic principles in the design and analysis of networked systems. The influence of incentives is fundamental when the users of a system have competing interests and may behave selfishly. In particular, networked systems are often sustained by resources contributed and controlled by their participants, and their resources are consumed by individual user choice but are managed as a commons for the benefit of the group. Contexts of particular interest for this workshop include Internet routing and traffic control, peer-to-peer services, distributed hosting platforms (utilities or grids), and wireless mesh networks. Topics of interest include, but are not limited to: - incentives and disincentives for cooperation in networked systems - empirical studies of strategic (or non-strategic) user behavior - strategic models and solution concepts for networked systems - distributed algorithmic mechanism design - economics of on-demand computing - payment and currency systems - reputation, trust, and anonymity vs. accountability - economic influences on network structure - network externalities and scale economies - public goods and club formation - accounting and settlement mechanisms - disruption and countermeasures for peer-to-peer content sharing The workshop will be held in conjunction with EC-06: ACM Conference on Electronic Commerce. The program will combine invited talks, paper presentations, and discussion. Authors should submit a position paper that expresses a novel or interesting problem, offers a specific solution, reports on actual experience, or advances a research agenda. Papers will be selected based on their originality, technical merit and topical relevance as well as the likelihood that they will lead to insightful discussions at the workshop. Accepted papers will be published on the workshop website. Submissions should be no more than 6 pages in length with 10pt fonts or larger. Submissions may include an appendix outside the page limit for review by the committee at its option. Submissions due: March 27, 2006 (8:00 PM US eastern time, no extensions) Notification of acceptance: April 30, 2006 Final papers due: May 29, 2006 Anticipated workshop date: June 11 Program Committee Jeff Chase, Duke University (co-chair) Nick Feamster, Georgia Tech (co-chair) Tim Roughgarden, Stanford (co-chair) Bobby Bhattacharjee, U. Maryland Landon Cox, Duke University George Danezis, K.U. Leuven Balachander Krishnamurthy, AT&T Research Ratul Mahajan, Microsoft Research David Parkes, Harvard University Rahul Sami, University of Michigan Emin Gun Sirer, Cornell Alex Snoeren, UCSD Don Towsley, U. Mass Amherst Xiaowei Yang, UC Irvine From imcdnzl at gmail.com Thu Feb 2 18:51:02 2006 From: imcdnzl at gmail.com (Ian McDonald) Date: Fri, 3 Feb 2006 15:51:02 +1300 Subject: [e2e] FW: Performance evaluation of high speed TCPs In-Reply-To: References: <39307.60.44.142.168.1138932213.squirrel@webmail.ncsu.edu> Message-ID: > Seriously, where's the value in comparing buggy implementations - isn't > that just a waste of all our time ? If we are genuine about wanting to > understand tcp performance then I think we just have to take the hit from > issues such as this that are outside all of our control. > A real part of the problem here is that the Linux doesn't have a full TCP testing suite and doesn't have build checking to check for regressions in TCP variants. As I understand the only thing tested in nightly builds is throughput for the default TCP. Stephen Hemminger has done some work on TCP Probes but this is where I think real progress could be made in improving Linux TCP. I may get around to doing this myself at some point in my research but would welcome other people doing it also! Ian -- Ian McDonald http://wand.net.nz/~iam4 WAND Network Research Group University of Waikato New Zealand From rhee at ncsu.edu Fri Feb 3 12:17:39 2006 From: rhee at ncsu.edu (rhee@ncsu.edu) Date: Fri, 3 Feb 2006 15:17:39 -0500 (EST) Subject: [e2e] FW: Performance evaluation of high speed TCPs In-Reply-To: References: <39307.60.44.142.168.1138932213.squirrel@webmail.ncsu.edu> <48677.60.44.142.168.1138935007.squirrel@webmail.ncsu.edu> Message-ID: <58352.61.86.155.104.1138997859.squirrel@webmail.ncsu.edu> Let's get off this e2e list for this discussion. It is really unnecessary to use this list for this discussion. I don't understand why you keep sending your email to this list even though we are seating next to each other in the same conference. Isn't this amusing or abusing of this mailing list? :-) -- to others in the list, Doug and I are attending pfldnet in japan now.. > Injong, > >>In fact, i contacted your student "Baruch" one month and half before we >> posted our > report -- it was CCed in the netdev mailing list as well and we gave him > login and > passwd on our result website (at that time we were just about to write the > report) > and we have not heard from your guys until just one week ago. At least we > did try to > make sure we are running a buggy version. > > We have no record of receiving such an email. Just a mix-up I guess. > > Doug > > >>>Seriously, we can't run the tests for every fix and bug report. >> >> Perhaps best to view it as returning a favour. You may recall that we >> re-ran all our own experimental tests last year (all data and code >> available online at www.hamilton.ie/net/eval/) on discovering a >> previously >> unreported bug introduced by the linux folks when implementing bic. >> Something similar has happened with importing htcp into linux. >> >> Seriously, where's the value in comparing buggy implementations - isn't >> that just a waste of all our time ? If we are genuine about wanting to >> understand tcp performance then I think we just have to take the hit >> from >> issues such as this that are outside all of our control. >> >> Doug >> >> Hamilton Institute >> www.hamilton.ie >> > > > > From matthew at cs.uni-bonn.de Wed Feb 8 02:43:30 2006 From: matthew at cs.uni-bonn.de (Matthias Frank) Date: Wed, 08 Feb 2006 11:43:30 +0100 Subject: [e2e] IEEE LCN 2006 Call for Papers Message-ID: <43E9CB52.8090301@cs.uni-bonn.de> ================================================================= Apologies if you receive multiple copies of this Call for Papers ================================================================= LCN 2006 The 31st Annual IEEE Conference on Local Computer Networks (LCN) http://www.ieeelcn.org Sponsored by the IEEE Computer Society with support from the University of South Florida College of Engineering. Tampa, Florida November 14-17, 2006 CALL FOR PAPERS The IEEE LCN conference is the premier conference on the leading edge of practical computer networking. LCN is a highly interactive conference that enables an effective interchange of results and ideas among researchers, users, and product developers. During 31 years of this conference, major developments from high-speed local networks to the global Internet to specialized sensor networks have been reported at this conference. We encourage you to submit original papers describing research results or practical solutions in leading edge topics. Paper topics include, but are not limited to: Ad hoc networks Adaptive applications Ambient networks Congestion control Embedded networks Location-dependent services High-speed access networks Mobility management Home and SOHO networks Multimedia communication Local area networks Network management Optical networks Network reliability and security Overlay networks Network traffic characterization Peer-to-peer networks Performance evaluation Personal and wearable networks Performance measurement and tuning Sensor networks Quality-of-Service Storage area networks Traffic shaping and control Wireless networks Ubiquitous networking Authors are invited to submit full or short papers for presentation at the conference. Full papers (no more than 8 camera-ready pages, 10 pt font in IEEE format) should present novel perspectives within the general scope of the conference. Short papers are an opportunity to present preliminary or interim results and are limited to 2 camera-ready pages in length. Short papers will be presented in a poster format and are published in the proceedings. All papers must include title, complete contact information for all authors, abstract, and keywords on the cover page. The corresponding author must be clearly identified. PAPER SUBMISSION: Papers must be submitted electronically in PDF. All submission instructions will be posted on the the conference website. Please direct your questions to the program co-chairs, Ken Christensen and Matthias Frank . IMPORTANT DATES: Paper submission deadline: May 12, 2006 Notification of acceptance: July 31, 2006 Camera-ready paper due: August 25, 2006 Author registration by: August 25, 2006 WORKSHOPS: A number of workshops will be co-located with the conference. Workshop papers will be published in the main proceedings. Information on workshops, submission deadlines and all other details will be posted on the conference web site. General Chair: - Hossam Hassanein, Queens University Program Chair: - Ken Christensen, University of South Florida Program Co-Chair: - Matthias Frank, University of Bonn Finance Chair: - Frank Huebner, AT&T Labs Local Arrangements Chair: - Miguel Labrador, University of South Florida Workshops Chair: - Mohamed Younis, University of Maryland, BC Publication Chair: - Ehab Elmallah, University of Alberta Publicity Chair: - Chun Tung Chou, University of New South Wales Corporate Relations Chair: - Tom Pfeifer, TSSG, Waterford IT, Ireland International Advisor: - Burkhard Stiller, University of Zurich and ETH Zurich Webmaster: - Gary Kessler, Champlain College Standing Committee: - Joe Bumblis, BAE Systems - Gary Kessler, Champlain College - Peter Martini, University of Bonn - Howard Salwen, Audeon Networks - Tim Strayer, BBN From detlef.bosau at web.de Sat Feb 11 09:31:31 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 11 Feb 2006 18:31:31 +0100 Subject: [e2e] TCP over mobile networks: Are there any problems left? Message-ID: <43EE1F73.B6664CC4@web.de> This question may sound somewhat stupid, but after having read about quite a few claimed "problems" with TCP over mobile network, I?m finally not sure whether there exist any or not. As one example, the frequently discussed spurious timeouts turn out to be a myth, when we look at "TCP Spurious Timeout estimation in an operational GPRS/UMTS network" by Francesco Vacirca, Thomas Ziegler and Eduard Hasenleithner. I?m somewhat puzzled here. I read about alleged problems here in quite a few papers for years, but when I have a closer look at them, most of the alleged problems are not really sound. So, I tend to say provokingly: "TCP over mobile networks works just fine as it is. There are no known problems left." Is this true? Or am I wrong here? -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From Jon.Crowcroft at cl.cam.ac.uk Mon Feb 13 03:49:17 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 13 Feb 2006 11:49:17 +0000 Subject: [e2e] 100% NAT - a DoS proof internet Message-ID: So there's three things here 1/ a mad idea for a DoS proof internet - This goes like this: What if 100% of hosts were behing a NAT (a bit like mark handley and adam greenhalgh's idea on a dos proof internet in fdna a while back, but taken to extreme, or also like default off paper in hotnets) So how would you ever reach someone (like most NAT traversal stuff is tricky - viz skype - see also below:) Meanwhile, here is how: Distributed Hashed Time. So we all know about DHTs - they hash an object to a node id, then use some p2p route to get to the node id (e.g. MIT's chord finger table etc etc). So if we want to talk to a set of known people, we hash their identifier (name) to TIME. We then send to each other at that agreed time - no-one else can send to us or from us to them, and the hash key can be a shared secret.... there you go...the details should be simple (apart from how you provide sufficiently accurate synchronized time without a globally reachable adddress betweewn the NTP servers, which, I admit, is probably a mite tricky - i guess you need to have them agree a set of rough times or something:) 2/ a pointer to something about a mad bad idea i had about control networks http://www.cl.cam.ac.uk/~jac22/press-release-backstory.htm 3/ a reminder of a workshop deadline - sorry:) (see website for more info on submissions) ------------------------------------------------------------------ PAPER SUBMISSION DEADLINE HAS BEEN EXTENDED TO 26 FEBRUARY 2006 ------------------------------------------------------------------ CALL FOR PAPERS Second International Workshop on Multi-hop Ad hoc Networks: from theory to reality REALMAN 2006 http://www.cl.cam.ac.uk/realman cheers jon From Jon.Crowcroft at cl.cam.ac.uk Mon Feb 13 05:46:39 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 13 Feb 2006 13:46:39 +0000 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: Message from Fred Baker of "Mon, 13 Feb 2006 07:26:22 EST." <3378EA87-1954-49F6-9CC8-8E91BD030650@cisco.com> Message-ID: In missive <3378EA87-1954-49F6-9CC8-8E91BD030650 at cisco.com>, Fred Baker typed: >>Are you telling me that you think that devices that are behind NATs >>don't get DOS'd? not by address scanning worms, no... >>I would prefer that you used the term "stateful firewall" as compared >>to "NAT"; NATs aren't necessarily stateful, and stateful firewall >>technology doesn't require network address translation to make it >>work. If the mapping between an interior address and an exterior >>address is predictable, the device behind can be DOS'd; the thing >>that a stateful firewall does is make the attack a bit harder to >>perpetrate. sure - so what i was proposing was a rendezvous mechanism for src/dst pairs of nodes and their globally reachable address allocation - so it can't be DOS'd normally, as it aint there, but temporally, and it aint there for anyone other than for this pair (multicast, tbd:) spatially i.e. ultra stateful (think of it as a VCI allocation mechanism with a capability:) >>Let me give you a simplistic example. If I have a SIP Proxy in a NAT >>system, so that SIP is made to traverse the firewall in a >>straightforward manner, SIP can then be used as an attack vector to >>the device it proxies for. That is but one. yes, in today's internet, but not in what i propose >>On Feb 13, 2006, at 6:49 AM, Jon Crowcroft wrote: >> >>> So there's three things here >>> >>> 1/ a mad idea for a DoS proof internet - This goes like this: >>> >>> What if 100% of hosts were behing a NAT (a bit like mark handley and >>> adam greenhalgh's idea on a dos proof internet in fdna a while back, >>> but taken to extreme, or also like default off paper in hotnets) >>> >>> So how would you ever reach someone (like most NAT traversal stuff is >>> tricky - viz skype - see also below:) >>> >>> Meanwhile, here is how: Distributed Hashed Time. >>> >>> So we all know about DHTs - they hash an object to a node id, then use >>> some p2p route to get to the node id (e.g. MIT's chord finger table >>> etc etc). >>> >>> So if we want to talk to a set of known people, we hash their >>> identifier (name) to TIME. We then send to each other at that agreed >>> time - no-one else can send to us or from us to them, and the hash key >>> can be a shared secret.... >>> >>> there you go...the details should be simple (apart from how you >>> provide sufficiently accurate synchronized time without a globally >>> reachable adddress betweewn the NTP servers, which, I admit, is >>> probably a mite tricky - i guess you need to have them agree a set of >>> rough times or something:) >>> >>> 2/ a pointer to something about a mad bad idea i had about control >>> networks >>> http://www.cl.cam.ac.uk/~jac22/press-release-backstory.htm >>> >>> 3/ a reminder of a workshop deadline - sorry:) >>> (see website for more info on submissions) >>> >>> ------------------------------------------------------------------ >>> PAPER SUBMISSION DEADLINE HAS BEEN EXTENDED TO >>> 26 FEBRUARY 2006 >>> ------------------------------------------------------------------ >>> >>> CALL FOR PAPERS >>> >>> Second International Workshop on >>> Multi-hop Ad hoc Networks: from theory to reality >>> REALMAN 2006 >>> http://www.cl.cam.ac.uk/realman >>> >>> >>> cheers >>> >>> jon cheers jon From philippe.gentric at philips.com Mon Feb 13 07:48:22 2006 From: philippe.gentric at philips.com (Philippe Gentric) Date: Mon, 13 Feb 2006 16:48:22 +0100 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: Message-ID: > there you go...the details should be simple (apart from how you > provide sufficiently accurate synchronized time without a globally > reachable adddress betweewn the NTP servers, which, I admit, is > probably a mite tricky http://europa.eu.int/comm/dgs/energy_transport/galileo/index_en.htm Philippe. From touch at ISI.EDU Mon Feb 13 08:18:51 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 13 Feb 2006 08:18:51 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <43F0B16B.2080107@isi.edu> Jon Crowcroft wrote: > In missive <3378EA87-1954-49F6-9CC8-8E91BD030650 at cisco.com>, Fred Baker typed: > > >>Are you telling me that you think that devices that are behind NATs > >>don't get DOS'd? > > not by address scanning worms, no... PS - Once they're all on a DHT, the worm will run on the DHT too ;-) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060213/0417acb0/signature.bin From touch at ISI.EDU Mon Feb 13 08:18:04 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 13 Feb 2006 08:18:04 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <43F0B13C.8080801@isi.edu> Hi, Jon, Jon Crowcroft wrote: > So there's three things here > > 1/ a mad idea for a DoS proof internet - This goes like this: > > What if 100% of hosts were behing a NAT (a bit like mark handley and > adam greenhalgh's idea on a dos proof internet in fdna a while back, > but taken to extreme, or also like default off paper in hotnets) > > So how would you ever reach someone (like most NAT traversal stuff is > tricky - viz skype - see also below:) > > Meanwhile, here is how: Distributed Hashed Time. > > So we all know about DHTs - they hash an object to a node id, then use > some p2p route to get to the node id (e.g. MIT's chord finger table > etc etc). > > So if we want to talk to a set of known people, we hash their > identifier (name) to TIME. We then send to each other at that agreed > time - no-one else can send to us or from us to them, and the hash key > can be a shared secret.... How do you "send to each other"? You need to talk to a host behind a NAT. You need to reach the service on that host that runs this DHTime protocol. You can have more than one host behind the NAT. A NAT basically makes everything behind it look like one host. There are two options: a. the host behind the NAT tries to reach the other host first this works only if the 'other host' is NOT behind a NAT, so we're out of luck b. you 'register' your host somewhere as owning a unique way to demultiplex packets to it A DHT does both of these - (a) to reach a node somewhere else that is NOT NAT'd first, then (b) to register in that infrastructure so other nodes can find it using its node ID. Two killer questions: 1. if everything is NAT'd, how do you perform step (a)? i.e., where is the first place you register? 2. (b) assumes hosts have unique node-IDs, but you went through a lot of trouble to remove that property (NATs) for every reason you had a NAT in the base net, why is it now acceptable to not NAT the node-IDs? - if you NAT node IDs, you're back where you started - if you're OK with not NAT'ing node IDs, why did you NAT the base net? i.e., non-NAT'd node IDs now become susceptible to every message on the DHT > there you go...the details should be simple (apart from how you > provide sufficiently accurate synchronized time without a globally > reachable adddress betweewn the NTP servers, which, I admit, is > probably a mite tricky - i guess you need to have them agree a set of > rough times or something:) Time, IMO, is the least of your concerns... Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060213/31739799/signature.bin From fred at cisco.com Mon Feb 13 04:26:22 2006 From: fred at cisco.com (Fred Baker) Date: Mon, 13 Feb 2006 07:26:22 -0500 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <3378EA87-1954-49F6-9CC8-8E91BD030650@cisco.com> Are you telling me that you think that devices that are behind NATs don't get DOS'd? I would prefer that you used the term "stateful firewall" as compared to "NAT"; NATs aren't necessarily stateful, and stateful firewall technology doesn't require network address translation to make it work. If the mapping between an interior address and an exterior address is predictable, the device behind can be DOS'd; the thing that a stateful firewall does is make the attack a bit harder to perpetrate. Let me give you a simplistic example. If I have a SIP Proxy in a NAT system, so that SIP is made to traverse the firewall in a straightforward manner, SIP can then be used as an attack vector to the device it proxies for. That is but one. On Feb 13, 2006, at 6:49 AM, Jon Crowcroft wrote: > So there's three things here > > 1/ a mad idea for a DoS proof internet - This goes like this: > > What if 100% of hosts were behing a NAT (a bit like mark handley and > adam greenhalgh's idea on a dos proof internet in fdna a while back, > but taken to extreme, or also like default off paper in hotnets) > > So how would you ever reach someone (like most NAT traversal stuff is > tricky - viz skype - see also below:) > > Meanwhile, here is how: Distributed Hashed Time. > > So we all know about DHTs - they hash an object to a node id, then use > some p2p route to get to the node id (e.g. MIT's chord finger table > etc etc). > > So if we want to talk to a set of known people, we hash their > identifier (name) to TIME. We then send to each other at that agreed > time - no-one else can send to us or from us to them, and the hash key > can be a shared secret.... > > there you go...the details should be simple (apart from how you > provide sufficiently accurate synchronized time without a globally > reachable adddress betweewn the NTP servers, which, I admit, is > probably a mite tricky - i guess you need to have them agree a set of > rough times or something:) > > 2/ a pointer to something about a mad bad idea i had about control > networks > http://www.cl.cam.ac.uk/~jac22/press-release-backstory.htm > > 3/ a reminder of a workshop deadline - sorry:) > (see website for more info on submissions) > > ------------------------------------------------------------------ > PAPER SUBMISSION DEADLINE HAS BEEN EXTENDED TO > 26 FEBRUARY 2006 > ------------------------------------------------------------------ > > CALL FOR PAPERS > > Second International Workshop on > Multi-hop Ad hoc Networks: from theory to reality > REALMAN 2006 > http://www.cl.cam.ac.uk/realman > > > cheers > > jon From Jon.Crowcroft at cl.cam.ac.uk Mon Feb 13 08:25:44 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 13 Feb 2006 16:25:44 +0000 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: Message from Joe Touch of "Mon, 13 Feb 2006 08:18:04 PST." <43F0B13C.8080801@isi.edu> Message-ID: there's no central anything - there is a pool of unallocated globally reachable addresses and a set of points (where, as yet, you can't ingress/egress) around the edge of the net - behind these points, one can cause a globally reachable address to be allocated for an egress w.r.t. an ingress for unidirectional communication at some time - so the other end can then try sending to it (only at that time) - this usefully has the side effect of allocating another globally reachable pinhole at the source so the sink (but noone else) could optionally answer thing of the time being a capability and this being a very virtual circuit. its not like IP, jim, at all. In missive <43F0B13C.8080801 at isi.edu>, Joe Touch typed: >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>--------------enig8AEE14DC4866D756D31CF09B >>Content-Type: text/plain; charset=ISO-8859-1 >>Content-Transfer-Encoding: quoted-printable >> >>Hi, Jon, >> >>Jon Crowcroft wrote: >>> So there's three things here >>>=20 >>> 1/ a mad idea for a DoS proof internet - This goes like this: >>>=20 >>> What if 100% of hosts were behing a NAT (a bit like mark handley and >>> adam greenhalgh's idea on a dos proof internet in fdna a while back,=20 >>> but taken to extreme, or also like default off paper in hotnets) >>>=20 >>> So how would you ever reach someone (like most NAT traversal stuff is >>> tricky - viz skype - see also below:) >>>=20 >>> Meanwhile, here is how: Distributed Hashed Time. >>>=20 >>> So we all know about DHTs - they hash an object to a node id, then use >>> some p2p route to get to the node id (e.g. MIT's chord finger table >>> etc etc). >>>=20 >>> So if we want to talk to a set of known people, we hash their >>> identifier (name) to TIME. We then send to each other at that agreed >>> time - no-one else can send to us or from us to them, and the hash key >>> can be a shared secret.... >> >>How do you "send to each other"? >> >>You need to talk to a host behind a NAT. You need to reach the service >>on that host that runs this DHTime protocol. You can have more than one >>host behind the NAT. A NAT basically makes everything behind it look >>like one host. >> >>There are two options: >> >> a. the host behind the NAT tries to reach the other host first >> this works only if the 'other host' is NOT behind >> a NAT, so we're out of luck >> >> b. you 'register' your host somewhere as owning a unique >> way to demultiplex packets to it >> >>A DHT does both of these - (a) to reach a node somewhere else that is >>NOT NAT'd first, then (b) to register in that infrastructure so other >>nodes can find it using its node ID. >> >>Two killer questions: >> >> 1. if everything is NAT'd, how do you perform step (a)? >> i.e., where is the first place you register? >> >> 2. (b) assumes hosts have unique node-IDs, but you >> went through a lot of trouble to remove that property (NATs) >> >> for every reason you had a NAT in the base net, >> why is it now acceptable to not NAT the node-IDs? >> >> - if you NAT node IDs, you're back where you started >> >> - if you're OK with not NAT'ing node IDs, why did you >> NAT the base net? >> i.e., non-NAT'd node IDs now become susceptible >> to every message on the DHT >> >>> there you go...the details should be simple (apart from how you >>> provide sufficiently accurate synchronized time without a globally >>> reachable adddress betweewn the NTP servers, which, I admit, is >>> probably a mite tricky - i guess you need to have them agree a set of >>> rough times or something:) >> >>Time, IMO, is the least of your concerns... >> >>Joe >> >> >>--------------enig8AEE14DC4866D756D31CF09B >>Content-Type: application/pgp-signature; name="signature.asc" >>Content-Description: OpenPGP digital signature >>Content-Disposition: attachment; filename="signature.asc" >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.1 (MingW32) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>iD8DBQFD8LE8E5f5cImnZrsRAlIaAJ9Dq0kBFWBmw5SzWpZBVSq6h94pMACg6EzY >>VBmeL/dEBX6qvumw8swM4TQ= >>=cuLP >>-----END PGP SIGNATURE----- >> >>--------------enig8AEE14DC4866D756D31CF09B-- cheers jon From touch at ISI.EDU Mon Feb 13 08:35:21 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 13 Feb 2006 08:35:21 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <43F0B549.4060709@isi.edu> Hi, Jon, Jon Crowcroft wrote: > there's no central anything - there is a pool of unallocated globally > reachable addresses and a set of points (where, as yet, you can't > ingress/egress) around the edge of the net - So let's start. In the beginning, there is no DHT. Your host and mine are behind NATs. Don't we FIRST need to join the DHT? How do we do that? > behind these points, one can cause a globally reachable address to be > allocated for an egress w.r.t. an ingress for unidirectional > communication at some time - so the other end can then try sending to > it (only at that time) - this usefully has the side effect of > allocating another globally reachable pinhole at the source so the > sink (but noone else) could optionally answer Allocating these addresses is what NAT's already do - some for a pool of addresses, some for an address/port pair. All that does is allow your host and my host to end up receiving incoming calls on those addresses. We still need to find each others' addresses; you haven't told us how to do that. The DHT by which we might find each other doesn't exist yet. -- Finally, whatever ID you want to expose to the world (DHT node ID, DNS name, etc.) just 'undoes' what the NAT did. Every reason you had for NAT'ing the host is a reason to "NAT" those IDs at some point, where you're back where you started. Joe > thing of the time being a capability and this being a > very virtual circuit. > > its not like IP, jim, at all. > > In missive <43F0B13C.8080801 at isi.edu>, Joe Touch typed: > > >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >>--------------enig8AEE14DC4866D756D31CF09B > >>Content-Type: text/plain; charset=ISO-8859-1 > >>Content-Transfer-Encoding: quoted-printable > >> > >>Hi, Jon, > >> > >>Jon Crowcroft wrote: > >>> So there's three things here > >>>=20 > >>> 1/ a mad idea for a DoS proof internet - This goes like this: > >>>=20 > >>> What if 100% of hosts were behing a NAT (a bit like mark handley and > >>> adam greenhalgh's idea on a dos proof internet in fdna a while back,=20 > >>> but taken to extreme, or also like default off paper in hotnets) > >>>=20 > >>> So how would you ever reach someone (like most NAT traversal stuff is > >>> tricky - viz skype - see also below:) > >>>=20 > >>> Meanwhile, here is how: Distributed Hashed Time. > >>>=20 > >>> So we all know about DHTs - they hash an object to a node id, then use > >>> some p2p route to get to the node id (e.g. MIT's chord finger table > >>> etc etc). > >>>=20 > >>> So if we want to talk to a set of known people, we hash their > >>> identifier (name) to TIME. We then send to each other at that agreed > >>> time - no-one else can send to us or from us to them, and the hash key > >>> can be a shared secret.... > >> > >>How do you "send to each other"? > >> > >>You need to talk to a host behind a NAT. You need to reach the service > >>on that host that runs this DHTime protocol. You can have more than one > >>host behind the NAT. A NAT basically makes everything behind it look > >>like one host. > >> > >>There are two options: > >> > >> a. the host behind the NAT tries to reach the other host first > >> this works only if the 'other host' is NOT behind > >> a NAT, so we're out of luck > >> > >> b. you 'register' your host somewhere as owning a unique > >> way to demultiplex packets to it > >> > >>A DHT does both of these - (a) to reach a node somewhere else that is > >>NOT NAT'd first, then (b) to register in that infrastructure so other > >>nodes can find it using its node ID. > >> > >>Two killer questions: > >> > >> 1. if everything is NAT'd, how do you perform step (a)? > >> i.e., where is the first place you register? > >> > >> 2. (b) assumes hosts have unique node-IDs, but you > >> went through a lot of trouble to remove that property (NATs) > >> > >> for every reason you had a NAT in the base net, > >> why is it now acceptable to not NAT the node-IDs? > >> > >> - if you NAT node IDs, you're back where you started > >> > >> - if you're OK with not NAT'ing node IDs, why did you > >> NAT the base net? > >> i.e., non-NAT'd node IDs now become susceptible > >> to every message on the DHT > >> > >>> there you go...the details should be simple (apart from how you > >>> provide sufficiently accurate synchronized time without a globally > >>> reachable adddress betweewn the NTP servers, which, I admit, is > >>> probably a mite tricky - i guess you need to have them agree a set of > >>> rough times or something:) > >> > >>Time, IMO, is the least of your concerns... > >> > >>Joe > >> > >> > >>--------------enig8AEE14DC4866D756D31CF09B > >>Content-Type: application/pgp-signature; name="signature.asc" > >>Content-Description: OpenPGP digital signature > >>Content-Disposition: attachment; filename="signature.asc" > >> > >>-----BEGIN PGP SIGNATURE----- > >>Version: GnuPG v1.4.1 (MingW32) > >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >> > >>iD8DBQFD8LE8E5f5cImnZrsRAlIaAJ9Dq0kBFWBmw5SzWpZBVSq6h94pMACg6EzY > >>VBmeL/dEBX6qvumw8swM4TQ= > >>=cuLP > >>-----END PGP SIGNATURE----- > >> > >>--------------enig8AEE14DC4866D756D31CF09B-- > > cheers > > jon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060213/8bd9c69a/signature-0001.bin From jeroen at unfix.org Mon Feb 13 08:51:52 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 13 Feb 2006 17:51:52 +0100 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <1139849512.19715.6.camel@firenze.zurich.ibm.com> On Mon, 2006-02-13 at 13:46 +0000, Jon Crowcroft wrote: > In missive <3378EA87-1954-49F6-9CC8-8E91BD030650 at cisco.com>, Fred Baker typed: > > >>Are you telling me that you think that devices that are behind NATs > >>don't get DOS'd? > > not by address scanning worms, no... Worms don't come in directly to the IP's that often, they spread mostly using email, broswers, and other applications and some unknowing user simply starting applications it should not be running. Host-based firewalls do a wonderful job here already. Of course there are some viri which scan semi-randomly but the effect is lower than a email containing a jucky picture of some teen celebrity. If you want to protect against address scans then move to IPv6 :) (though one infected box and they have the local subnet) Also, the target of the DoS will just shift with your idea, from the end-host to the NAT box that is 'protecting' it. Which in turn make it actually harder to work against these attacks. Just read up on some of the timelines about attacks against IRC servers. First the targetted the irc servers themselves, after that they started dos'sing the links, which simply means they will kill of the routers in between the user and the server.. There is no real magic bullet. Law and especially enforcement is one of the few things that might help a bit, but that is not something we might want to see from the e2e point of view. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060213/826dfb11/attachment.bin From sboone at cs.hmc.edu Mon Feb 13 09:12:38 2006 From: sboone at cs.hmc.edu (Scott Boone) Date: Mon, 13 Feb 2006 09:12:38 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <20060213171238.GA4952@turing.cs.hmc.edu> [ insert anecdotate about "why security through obscurity doesn't work" here ] (scott) From huitema at windows.microsoft.com Mon Feb 13 10:19:51 2006 From: huitema at windows.microsoft.com (Christian Huitema) Date: Mon, 13 Feb 2006 10:19:51 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <1139849512.19715.6.camel@firenze.zurich.ibm.com> Message-ID: > Worms don't come in directly to the IP's that often, they spread mostly > using email, broswers, and other applications and some unknowing user > simply starting applications it should not be running. Host-based > firewalls do a wonderful job here already. Of course there are some viri > which scan semi-randomly but the effect is lower than a email containing > a jucky picture of some teen celebrity. Jeroen is right. If you look at "DOS topology", there is very little difference between an external firewall (Jon's NAT) and a host firewall. It is just a different way to build the distributed system. Jon may object that, from a practical point of view, an external box is "more secure" since it is small, does exactly one thing, does it well, etc. But on the other hand, the small box is a commodity component, sold with a razor thin margin. Even small boxes do have bugs, and it is much easier for users to apply a patch downloaded from Windows Update than to try to re-flash the firmware of a router. I don't know whether Jon's "rendezvous on time" proposal actually solve DOS issues, but it is interesting for other reasons. It enables "private rendezvous in a public world". The parties conspire to publish a name (the rendezvous point) that changes frequently and cannot be easily guessed by third parties. That is indeed quite interesting, because now only authorized peers can track someone's presence on the internet. Of course, private naming is only one element in the privacy puzzle. For example, changing the name is not very interesting if the IP address remains constant or if external sites can track someone's presence using cookies. -- Christian Huitema From dpreed at reed.com Mon Feb 13 11:36:10 2006 From: dpreed at reed.com (David P. Reed) Date: Mon, 13 Feb 2006 14:36:10 -0500 Subject: [e2e] security through obscurity *does* work - keep an open mind... In-Reply-To: <20060213171238.GA4952@turing.cs.hmc.edu> References: <20060213171238.GA4952@turing.cs.hmc.edu> Message-ID: <43F0DFAA.2090301@reed.com> Scott Boone wrote: >[ insert anecdotate about "why security through > obscurity doesn't work" here ] > Actually, cryptography is merely "security through obscurity". The only issue is the work factor involved. It's perfectly reasonable, IMHO, to use precise timing correlation filters vs. keyed sequence filters (e.g., PR sequences generated algorithmically from a key that has relatively low entropy generated from a 6-8 character mnemonic password) as the mechanism to raise the work factor. There's no a priori reason that precisely controllable timing can't generate high robustness against attacks. Remember that DDoS attacks, for example, gain some of their power by synchronization, so limiting the ability to synchronize collective action would raise the work factor threshold for DDoS. Reasoning by slogan is dangerous - that's more or less how we end up with MD5 being viewed as "secure" as it was... Or those who are ignorant of evanescent waves saying such boners as "you can't tap optical fibers without detection because you have to break them; you can't inject signals into optical fibers without detection because that can only be done at the endpoints". Such scientific ignorance provides no protection at all... From sboone at cs.hmc.edu Mon Feb 13 17:20:50 2006 From: sboone at cs.hmc.edu (Scott Boone) Date: Mon, 13 Feb 2006 17:20:50 -0800 Subject: [e2e] security through obscurity *does* work - keep an open mind... In-Reply-To: <43F0DFAA.2090301@reed.com> References: <20060213171238.GA4952@turing.cs.hmc.edu> <43F0DFAA.2090301@reed.com> Message-ID: <7D489497-856E-43C7-A6F6-B3E7EF7C48ED@cs.hmc.edu> On 13 Feb 2006, at 11:36 AM, David P. Reed wrote: > Scott Boone wrote: > >> [ insert anecdotate about "why security through obscurity doesn't >> work" here ] >> > Actually, cryptography is merely "security through obscurity". > The only issue is the work factor involved. > > It's perfectly reasonable, IMHO, to use precise timing correlation > filters vs. keyed sequence filters (e.g., PR sequences generated > algorithmically from a key that has relatively low entropy > generated from a 6-8 character mnemonic password) as the mechanism > to raise the work factor. > > There's no a priori reason that precisely controllable timing can't > generate high robustness against attacks. Remember that DDoS > attacks, for example, gain some of their power by synchronization, > so limiting the ability to synchronize collective action would > raise the work factor threshold for DDoS. do not use slogans on e2e. check. my slogan-related concern did not have anything to do with how secure the identification of the host itself was. my remark had more to do with the following issue: 1) something somewhere (edge routers, NAT boxes) has to have globally reachable addresses. these are still attackable. hiding some IDs doesn't hide all IDs, and is of limited utility. it is unclear to me how much you will gain by obfuscating a host's IP; my understanding (mostly obtained from a skimming the occasional NANOG and CAIDA presentation) is that serious DDoS attacks tend to impact edge routers and links. furthermore: 2) the control mechanism used to negotiate DHTs between pairs must have a globally reachable address. this address can be sniffed by an attacker. therefore, this approach is subject to a control plane attack. 3) any DHT implementation is going to have libraries that an intelligently designed worm will be able to call, which should then allow said worm to circumvent any host ID obfuscation. it makes a worm's job harder but does not force the worm to have to break the hash. and the elephant in the room: 4) many application use patterns on the internet would not play nicely with protocols that require two nodes to prearrange communications time in advance through a third party broker. how do two nodes even know they both want to talk to each other beforehand in most cases (e.g. http)? most internet services have to be globally reachable and open to requests from anywhere. > Reasoning by slogan is dangerous - that's more or less how we end > up with MD5 being viewed as "secure" as it was... that's certainly an ironic example given the slogan I used. > Or those who are ignorant of evanescent waves saying such boners as > "you can't tap optical fibers without detection because you have to > break them; you can't inject signals into optical fibers without > detection because that can only be done at the endpoints". Such > scientific ignorance provides no protection at all... 'reasoning by irrelevant tangent' is dangerous too. (scott) From dpreed at reed.com Mon Feb 13 19:09:28 2006 From: dpreed at reed.com (David P. Reed) Date: Mon, 13 Feb 2006 22:09:28 -0500 Subject: [e2e] security through obscurity *does* work - keep an open mind... In-Reply-To: <7D489497-856E-43C7-A6F6-B3E7EF7C48ED@cs.hmc.edu> References: <20060213171238.GA4952@turing.cs.hmc.edu> <43F0DFAA.2090301@reed.com> <7D489497-856E-43C7-A6F6-B3E7EF7C48ED@cs.hmc.edu> Message-ID: <43F149E8.4030901@reed.com> Scott Boone wrote: > > my slogan-related concern did not have anything to do with how secure > the identification of the host itself was. my remark had more to do > with the following issue: > > 1) something somewhere (edge routers, NAT boxes) has to have globally > reachable addresses. these are still attackable. hiding some IDs > doesn't hide all IDs, and is of limited utility. it is unclear to me > how much you will gain by obfuscating a host's IP; my understanding > (mostly obtained from a skimming the occasional NANOG and CAIDA > presentation) is that serious DDoS attacks tend to impact edge > routers and links. > Jon Crowcroft is focused on reducing the ability to do DDoS by making it hard to construct "botnets" that can act in concert on a sufficiently large scale to pose danger to large targets. This has nothing to do with global reachability of targets, or where the targets are. It's probably impossible to obscure the targets, anyway - the key thing about targets is that they must be reachable in order to be useful in their day jobs (when not being targets), since many of the most important targets must *by definition* be well-known and globally reachable by many. Since slowing access or limiting reachability denies service in and of itself, it's probably not a good solution to a DDoS risk to self-impose denial of service to one's customers. I apologize for including additional tangential comments regarding reasoning by slogans. However, nothing you've said bears on my main point. It is true that "security by obscurity" is too vague a phrase to reason with, and thus really should be avoided if one is attempting to come to a valid conclusion based on careful, rational argumentation. As I began my argument: the whole value of cryptography is tied precisely to the construction of obscurity - hiding information that in principle can be recovered, but at a cost that is thought to be prohibitive. What creates weakness is "security through limited opacity easily removed", not "security through 'provably costly to invert' obscurity". Since both are within the scope of meaning of the term "obscurity", the use of the phrase "security through obscurity" contributes nothing substantial to the discussion. Quantitative reasoning is required, as well as valid assumptions about knowledge available to the participants through side channels (again depending on ignorance, aka obscurity). From Jon.Crowcroft at cl.cam.ac.uk Tue Feb 14 01:28:25 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 14 Feb 2006 09:28:25 +0000 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: Message from Joe Touch of "Mon, 13 Feb 2006 08:18:04 PST." <43F0B13C.8080801@isi.edu> Message-ID: um, i think you need to re-read about DHTs and consistent hashes what yo uare talking about is the peer-to-peer routing part of some structured DHTs - this is thigns like the finger table in chord, or the prefix routing in pastry - i didnt say I was using any of that - i am _just_ using a DHT to do the time slot allocation in a way that is decentralised and agreed but not known except by agreement (made externally to this mechanism - as must _any_ security scheme have) between sender and recipient. yes, there are attacks on the external mechanism (and there are attacks on the routing) but saying there are attacks on X so your mechanism to defend on attacks on Y is pointless, is completely bogus too... In missive <43F0B13C.8080801 at isi.edu>, Joe Touch typed: >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>--------------enig8AEE14DC4866D756D31CF09B >>Content-Type: text/plain; charset=ISO-8859-1 >>Content-Transfer-Encoding: quoted-printable >> >>Hi, Jon, >> >>Jon Crowcroft wrote: >>> So there's three things here >>>=20 >>> 1/ a mad idea for a DoS proof internet - This goes like this: >>>=20 >>> What if 100% of hosts were behing a NAT (a bit like mark handley and >>> adam greenhalgh's idea on a dos proof internet in fdna a while back,=20 >>> but taken to extreme, or also like default off paper in hotnets) >>>=20 >>> So how would you ever reach someone (like most NAT traversal stuff is >>> tricky - viz skype - see also below:) >>>=20 >>> Meanwhile, here is how: Distributed Hashed Time. >>>=20 >>> So we all know about DHTs - they hash an object to a node id, then use >>> some p2p route to get to the node id (e.g. MIT's chord finger table >>> etc etc). >>>=20 >>> So if we want to talk to a set of known people, we hash their >>> identifier (name) to TIME. We then send to each other at that agreed >>> time - no-one else can send to us or from us to them, and the hash key >>> can be a shared secret.... >> >>How do you "send to each other"? >> >>You need to talk to a host behind a NAT. You need to reach the service >>on that host that runs this DHTime protocol. You can have more than one >>host behind the NAT. A NAT basically makes everything behind it look >>like one host. >> >>There are two options: >> >> a. the host behind the NAT tries to reach the other host first >> this works only if the 'other host' is NOT behind >> a NAT, so we're out of luck >> >> b. you 'register' your host somewhere as owning a unique >> way to demultiplex packets to it >> >>A DHT does both of these - (a) to reach a node somewhere else that is >>NOT NAT'd first, then (b) to register in that infrastructure so other >>nodes can find it using its node ID. >> >>Two killer questions: >> >> 1. if everything is NAT'd, how do you perform step (a)? >> i.e., where is the first place you register? >> >> 2. (b) assumes hosts have unique node-IDs, but you >> went through a lot of trouble to remove that property (NATs) >> >> for every reason you had a NAT in the base net, >> why is it now acceptable to not NAT the node-IDs? >> >> - if you NAT node IDs, you're back where you started >> >> - if you're OK with not NAT'ing node IDs, why did you >> NAT the base net? >> i.e., non-NAT'd node IDs now become susceptible >> to every message on the DHT >> >>> there you go...the details should be simple (apart from how you >>> provide sufficiently accurate synchronized time without a globally >>> reachable adddress betweewn the NTP servers, which, I admit, is >>> probably a mite tricky - i guess you need to have them agree a set of >>> rough times or something:) >> >>Time, IMO, is the least of your concerns... >> >>Joe >> >> >>--------------enig8AEE14DC4866D756D31CF09B >>Content-Type: application/pgp-signature; name="signature.asc" >>Content-Description: OpenPGP digital signature >>Content-Disposition: attachment; filename="signature.asc" >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.1 (MingW32) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>iD8DBQFD8LE8E5f5cImnZrsRAlIaAJ9Dq0kBFWBmw5SzWpZBVSq6h94pMACg6EzY >>VBmeL/dEBX6qvumw8swM4TQ= >>=cuLP >>-----END PGP SIGNATURE----- >> >>--------------enig8AEE14DC4866D756D31CF09B-- cheers jon From Jon.Crowcroft at cl.cam.ac.uk Tue Feb 14 01:32:23 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 14 Feb 2006 09:32:23 +0000 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: Message from Jeroen Massar of "Mon, 13 Feb 2006 17:51:52 +0100." <1139849512.19715.6.camel@firenze.zurich.ibm.com> Message-ID: In missive <1139849512.19715.6.camel at firenze.zurich.ibm.com>, Jeroen Massar typ ed: >>Worms don't come in directly to the IP's that often, they spread mostly >>using email, broswers, and other applications and some unknowing user >>simply starting applications it should not be running. Host-based >>firewalls do a wonderful job here already. Of course there are some viri >>which scan semi-randomly but the effect is lower than a email containing >>a jucky picture of some teen celebrity. 1/ I am not defending against vulnerabilities but against dos and scans >>If you want to protect against address scans then move to IPv6 :) >>(though one infected box and they have the local subnet) I use a MAC _ it uses IPv6 by default if its there - problem is the ISPs dont :-( your move. >>Also, the target of the DoS will just shift with your idea, from the >>end-host to the NAT box that is 'protecting' it. Which in turn make it >>actually harder to work against these attacks. Just read up on some of >>the timelines about attacks against IRC servers. First the targetted the >>irc servers themselves, after that they started dos'sing the links, >>which simply means they will kill of the routers in between the user and >>the server.. saying dont defend against X because everyone will move to attacking Y is bogus. >>There is no real magic bullet. Law and especially enforcement is one of >>the few things that might help a bit, but that is not something we might >>want to see from the e2e point of view. gosh, we have law already and its working so well isnt it:) i didnt say this was a magic bullet - i said it was an idea for defending against a specific problem. yes there are many problems and the design space for solutions is multi-faceted. security people love to attack things - i disdain that- i like to defend things:) cheers jon From Jon.Crowcroft at cl.cam.ac.uk Tue Feb 14 01:34:02 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 14 Feb 2006 09:34:02 +0000 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: Message from "Angelos D. Keromytis" of "Mon, 13 Feb 2006 12:43:04 EST." <43F0C528.70607@cs.columbia.edu> Message-ID: exactly. linear sequential address space scans are old hat - but I wasnt proposing an obscurity thing - as per my messages, i was propsing default OFF from/to everywhere and only ON on a host pair/time basis. IPv6 is orthogonal In missive <43F0C528.70607 at cs.columbia.edu>, "Angelos D. Keromytis" typed: >>Jeroen Massar wrote: >>> >>> If you want to protect against address scans then move to IPv6 :) >>> (though one infected box and they have the local subnet) >> >>Definitely true on the latter, as we point out on a recent paper on >>USENIX ;login: with Steve Bellovin and Bill Cheswick: >> >>http://www1.cs.columbia.edu/~angelos/Papers/2006/ipv6worm.pdf >> >>Furthermore, the worm can do a scanning of the DNS space and spread >>almost as fast as an IPv4 address-scanning worm. For example, see our >>INFOCOM 2005 paper: >> >>http://www1.cs.columbia.edu/~angelos/Papers/2005/dns-worm.pdf >> >>Cheers, >>-Angelos cheers jon From jeroen at unfix.org Tue Feb 14 03:23:04 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 14 Feb 2006 12:23:04 +0100 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <1139916184.27853.32.camel@firenze.zurich.ibm.com> On Mon, 2006-02-13 at 12:43 -0500, Angelos D. Keromytis wrote: > Jeroen Massar wrote: > > > > If you want to protect against address scans then move to IPv6 :) > > (though one infected box and they have the local subnet) > > Definitely true on the latter, as we point out on a recent paper on > USENIX ;login: with Steve Bellovin and Bill Cheswick: > > http://www1.cs.columbia.edu/~angelos/Papers/2006/ipv6worm.pdf This one I already got forwarded by some other folks, in the context of this thread, the part on "Peer-to-Peer protocols" also explains that one can monitor those networks to find out possible targets. This could be done more or less the same as with the proposed solution. > Furthermore, the worm can do a scanning of the DNS space and spread > almost as fast as an IPv4 address-scanning worm. For example, see our > INFOCOM 2005 paper: > > http://www1.cs.columbia.edu/~angelos/Papers/2005/dns-worm.pdf DNSSEC also gives an additional vector here where the NSEC records allows following and thus scanning the chain. But afaik they found a trick against this already (I am not tightly following dnssec). On Tue, 2006-02-14 at 09:32 +0000, Jon Crowcroft wrote: > In missive <1139849512.19715.6.camel at firenze.zurich.ibm.com>, Jeroen Massar typ > ed: > > >>Worms don't come in directly to the IP's that often, they spread mostly > >>using email, broswers, and other applications and some unknowing user > >>simply starting applications it should not be running. Host-based > >>firewalls do a wonderful job here already. Of course there are some viri > >>which scan semi-randomly but the effect is lower than a email containing > >>a jucky picture of some teen celebrity. > > 1/ I am not defending against vulnerabilities but against dos and > scans In the case of DoS, it is just a matter of having enough zombies saturate some point of the uplink or just the weakest link. The best DoS is similar to the slashdot effect: very large number of hosts following the protocol by the letter and not doing anything you did not expect. There is currently no way to detect the legit from the illegit traffic and thus you end up accepting everything and trying to cope or shutting down parts but then might end up shutting down legit traffic. Having some form of captcha in the protocol could work here though, but would require a lot of human intervention and would not be applicable for a lot of cases. DoS is a endsystem problem, when those can be compromised, and they will be, there is nothing to stop vermin to abuse them to do something which looks okay but what isn't. A scan is pretty useless, except for the knowledge part, when there is no vulnerability to exploit it. > >>If you want to protect against address scans then move to IPv6 :) > >>(though one infected box and they have the local subnet) > > I use a MAC _ it uses IPv6 by default if its there - > problem is the ISPs dont :-( > your move. A very easy move: http://www.sixxs.net or google("10 steps ipv6") (Chess, mate ;) Seeing that your mail address is based in the ac.uk part, you might want to check even things closer to you. There are 2 ac.uk based brokers at: http://www.sixxs.net/tools/aiccu/brokers/ which also lists a large number of other places to get connectivity from. In the ac.uk area most likely Tim Chown is able to tell you quite well where to get good quality connectivity from. If you need any help in getting IPv6 set up and running don't hesitate to ask. No firewall or other blocking mechanism has kept me from getting IPv6 connectivity ;) > >>Also, the target of the DoS will just shift with your idea, from the > >>end-host to the NAT box that is 'protecting' it. Which in turn make it > >>actually harder to work against these attacks. Just read up on some of > >>the timelines about attacks against IRC servers. First the targetted the > >>irc servers themselves, after that they started dos'sing the links, > >>which simply means they will kill of the routers in between the user and > >>the server.. > > > saying dont defend against X because everyone will move to attacking Y > is bogus. It's 'bogus' because? I just noted that the attack will move to another place and in many cases it will be a place which is harder to defend. Keeping it simple is then better ;) > >>There is no real magic bullet. Law and especially enforcement is one of > >>the few things that might help a bit, but that is not something we might > >>want to see from the e2e point of view. > > gosh, we have law already and its working so well isnt it:) Note the 'especially' in that sentence, the enforcement is not there and if it was it would be made corrupt next to limitting freedom which is not what is wanted either. But that is politics, not technicallities and I don't like the first ;) > i didnt say this was a magic bullet - i said it was an idea for > defending against a specific problem. yes there are many problems and > the design space for solutions is multi-faceted. > > security people love to attack things - i disdain that- i like to > defend things:) But having to build defense upon defense, which is what you want to do by shifting the problem, is certainly not going to help. It will end up in a walled garden with mostly walls and not garden. It will keep you defending but I am pretty sure you'd rather sit on a lazy couch or do something else than keeping an eye out all the time. Of course from a research/work perspective it is fun but is it worth the effort? Better have something really good which can't be broken/circumvented too easily. In this problem space though, having legit traffic already breaks most of the solutions. But keep ideas coming of course, it might be that something gives somebody a great idea which does solve a large part of the problem. I am unfortunately quite a bit on the pessimistic side when it comes to (d)dos solvers, could be because of the amounts of traffic I have seen coming in after some 14 year old didn't get what he wanted and forgot to stop that part of the botnet when his mom called for dinner... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060214/5237936c/attachment-0001.bin From Jon.Crowcroft at cl.cam.ac.uk Tue Feb 14 04:13:31 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 14 Feb 2006 12:13:31 +0000 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: Message from Jeroen Massar of "Tue, 14 Feb 2006 12:23:04 +0100." <1139916184.27853.32.camel@firenze.zurich.ibm.com> Message-ID: In missive <1139916184.27853.32.camel at firenze.zurich.ibm.com>, Jeroen Massar ty ped: >>> >>If you want to protect against address scans then move to IPv6 :) >>> >>(though one infected box and they have the local subnet) >>> I use a MAC _ it uses IPv6 by default if its there -=20 >>> problem is the ISPs dont :-( >>> your move. >>A very easy move: http://www.sixxs.net or google("10 steps ipv6") >>(Chess, mate ;) i can use ipv6 yes, but it aint end to end is my point - until it is, it doesn't provide as solid an approach as I'd like - but it is a start >>Seeing that your mail address is based in the ac.uk part, you might want >>to check even things closer to you. There are 2 ac.uk based brokers at: >>http://www.sixxs.net/tools/aiccu/brokers/ which also lists a large >>number of other places to get connectivity from. In the ac.uk area most >>likely Tim Chown is able to tell you quite well where to get good >>quality connectivity from. gosh, i was involved in ipv6 design too - i am a fan...!!! >>If you need any help in getting IPv6 set up and running don't hesitate >>to ask. No firewall or other blocking mechanism has kept me from getting >>IPv6 connectivity ;) but it aint end2end coz no tier1 runs it in th core.... >>> >>Also, the target of the DoS will just shift with your idea, from the >>> >>end-host to the NAT box that is 'protecting' it. Which in turn make it >>> >>actually harder to work against these attacks. Just read up on some of >>> >>the timelines about attacks against IRC servers. First the targetted t= >>he >>> >>irc servers themselves, after that they started dos'sing the links, >>> >>which simply means they will kill of the routers in between the user a= >>nd >>> >>the server.. >>> saying dont defend against X because everyone will move to attacking Y >>> is bogus. >> >>It's 'bogus' because? I just noted that the attack will move to another >>place and in many cases it will be a place which is harder to defend. >>Keeping it simple is then better ;) not if the current DOS attacks are a problem - and they are! plus enforcement or other places may be easier to defend (e.g. no legacy software there) for exampl,e so you can't just say "it moves elsewhere" - by your own argument, you have to show that "it moves elswhere to somewhere harder, not easier, to defend". >>> >>There is no real magic bullet. Law and especially enforcement is one o= >>f >>> >>the few things that might help a bit, but that is not something we mig= >>ht >>> >>want to see from the e2e point of view. >>>=20 >>> gosh, we have law already and its working so well isnt it:) >>Note the 'especially' in that sentence, the enforcement is not there and >>if it was it would be made corrupt next to limitting freedom which is >>not what is wanted either. But that is politics, not technicallities and >>I don't like the first ;) sure - see my _original_ mesage - it has links to a LOT of work we do on this PLUS on politics and regulation. >>> i didnt say this was a magic bullet - i said it was an idea for >>> defending against a specific problem. yes there are many problems and >>> the design space for solutions is multi-faceted. >>> security people love to attack things - i disdain that- i like to >>> defend things:) >> >>But having to build defense upon defense, which is what you want to do >>by shifting the problem, is certainly not going to help. It will end up >>in a walled garden with mostly walls and not garden. It will keep you >>defending but I am pretty sure you'd rather sit on a lazy couch or do >>something else than keeping an eye out all the time. Of course from a >>research/work perspective it is fun but is it worth the effort? Better >>have something really good which can't be broken/circumvented too >>easily. In this problem space though, having legit traffic already >>breaks most of the solutions. But keep ideas coming of course, it might >>be that something gives somebody a great idea which does solve a large >>part of the problem. I am unfortunately quite a bit on the pessimistic >>side when it comes to (d)dos solvers, could be because of the amounts of >>traffic I have seen coming in after some 14 year old didn't get what he >>wanted and forgot to stop that part of the botnet when his mom called >>for dinner... indeed - this is a VERY important point with wich i can agree my proposal isn't a solution - its a thinking point and I agree it does potentially create walled gardens which is (i think) your best objection to it! cheers j. From touch at ISI.EDU Tue Feb 14 07:49:12 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 14 Feb 2006 07:49:12 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <43F1FBF8.10409@isi.edu> Jon Crowcroft wrote: > um, i think you need to re-read about DHTs and consistent hashes What I was saying was that this variant won't work behind a NAT. I mistook that from your initial post; I still consider it accurate, but it may be off topic. However.... This is basically just frequency allocation. Each algorithm would have its preferred frequency; assuming that endpoints are sync'd, you 'meet' on the same frequency as the other end you want to speak with. Unfortunately, unless the algorithm or some mutual offset (aka 'key') between the endpoints is predeployed, the attacker code will know (and use) the same mechanism and with the same algorithm. I.e., it'll send a DHTime request, get a meeting time, and send its attack that way. Either this will slow down legitimate applications, or attackers will just mimic legitimate applications and move on. Time-based attacks are not uncommon - consider window attacks on TCP. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060214/a63e3fc8/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Tue Feb 14 08:12:21 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 14 Feb 2006 16:12:21 +0000 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: Message from Joe Touch of "Tue, 14 Feb 2006 07:49:12 PST." <43F1FBF8.10409@isi.edu> Message-ID: In missive <43F1FBF8.10409 at isi.edu>, Joe Touch typed: >>Jon Crowcroft wrote: >>> um, i think you need to re-read about DHTs and consistent hashes >>What I was saying was that this variant won't work behind a NAT. I >>mistook that from your initial post; I still consider it accurate, but >>it may be off topic. >>However.... >>This is basically just frequency allocation. Each algorithm would have >>its preferred frequency; assuming that endpoints are sync'd, you 'meet' >>on the same frequency as the other end you want to speak with. yes, kind of! >>Unfortunately, unless the algorithm or some mutual offset (aka 'key') >>between the endpoints is predeployed, the attacker code will know (and >>use) the same mechanism and with the same algorithm. I.e., it'll send a >>DHTime request, get a meeting time, and send its attack that way. right >>Either this will slow down legitimate applications, or attackers will >>just mimic legitimate applications and move on. Time-based attacks are >>not uncommon - consider window attacks on TCP. that is a good point! >> >> >> >>--------------enigF8FF148498E264F17EE76BD4 >>Content-Type: application/pgp-signature; name="signature.asc" >>Content-Description: OpenPGP digital signature >>Content-Disposition: attachment; filename="signature.asc" >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.1 (MingW32) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>iD8DBQFD8fv4E5f5cImnZrsRApynAJ9lK/An8IhoC6Wba5wpCeAThoE3bACglicl >>2LNhmBx1XwSBDMkaAQl1XU8= >>=7+Vr >>-----END PGP SIGNATURE----- >> >>--------------enigF8FF148498E264F17EE76BD4-- cheers jon From perfgeek at mac.com Tue Feb 14 08:25:02 2006 From: perfgeek at mac.com (rick jones) Date: Tue, 14 Feb 2006 08:25:02 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <854a478f524f35cd0b3489e092888aec@mac.com> On Feb 13, 2006, at 3:49 AM, Jon Crowcroft wrote: > So if we want to talk to a set of known people, we hash their > identifier (name) to TIME. We then send to each other at that agreed > time - no-one else can send to us or from us to them, and the hash key > can be a shared secret.... _almost_ sounds like a UUCP network (from what little I know of UUCP) - nodes would call each other at agreed-upon times, exchange their email/netnews/whatever and then move-on. wasn't terribly interactive though was it? rick jones Wisdom teeth are impacted, people are affected by the effects of events From huitema at windows.microsoft.com Tue Feb 14 12:37:23 2006 From: huitema at windows.microsoft.com (Christian Huitema) Date: Tue, 14 Feb 2006 12:37:23 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43F1FBF8.10409@isi.edu> Message-ID: > Jon Crowcroft wrote: > > um, i think you need to re-read about DHTs and consistent hashes > > What I was saying was that this variant won't work behind a NAT. I > mistook that from your initial post; I still consider it accurate, but > it may be off topic. Protecting DHT against DOS attacks is indeed a big issue. Consider: 1) The nodes participating in the DHT need an open communication port which is ipso facto a target for DOS attacks, 2) The nodes observing the DHT learn these ports, and also the addresses of many other nodes, enabling various forms of attack propagation, 3) The DHT application itself can be victim of DOS attacks, e.g. various forms of name injection, query overload, response spoofing. In fact, solving such issues is an interesting challenge for end-to-end researchers! -- Christian Huitema From touch at ISI.EDU Tue Feb 14 13:16:28 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 14 Feb 2006 13:16:28 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <43F248AC.1000305@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Huitema wrote: >>Jon Crowcroft wrote: >> >>>um, i think you need to re-read about DHTs and consistent hashes >> >>What I was saying was that this variant won't work behind a NAT. I >>mistook that from your initial post; I still consider it accurate, but >>it may be off topic. Per below, "off topic" in response to Jon's initial post, not "off topic for this list". (FWIW, all my recent posts have been individual; I usually sign posts as list admin as such) > Protecting DHT against DOS attacks is indeed a big issue. Consider: > > 1) The nodes participating in the DHT need an open communication port > which is ipso facto a target for DOS attacks, > 2) The nodes observing the DHT learn these ports, and also the addresses > of many other nodes, enabling various forms of attack propagation, > 3) The DHT application itself can be victim of DOS attacks, e.g. various > forms of name injection, query overload, response spoofing. > > In fact, solving such issues is an interesting challenge for end-to-end > researchers! Yes, DHT under DOS attacks is. IMO, DHT behind NATs is too, but AFAICT they don't work behind NATs any better than any other application-layer service. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8kisE5f5cImnZrsRArS3AKC/chUB1U1lE88sxwueVPorCEzo+ACgqnk0 /mo+vupBj2oJyFjqj0R50Ps= =aJOy -----END PGP SIGNATURE----- From angelos at cs.columbia.edu Tue Feb 14 13:56:54 2006 From: angelos at cs.columbia.edu (Angelos D. Keromytis) Date: Tue, 14 Feb 2006 16:56:54 -0500 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <43F25226.1080108@cs.columbia.edu> We have a tech report on the subject of DoS attacks inside a DHT: http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-019-04.pdf It's a little dated (and too math-heavy)...we have a paper currently under submission that refines the idea in the tech report and also presents a Pushback-like defense... Cheers, -Angelos Christian Huitema wrote: >>Jon Crowcroft wrote: >> >>>um, i think you need to re-read about DHTs and consistent hashes >> >>What I was saying was that this variant won't work behind a NAT. I >>mistook that from your initial post; I still consider it accurate, but >>it may be off topic. > > > Protecting DHT against DOS attacks is indeed a big issue. Consider: > > 1) The nodes participating in the DHT need an open communication port > which is ipso facto a target for DOS attacks, > 2) The nodes observing the DHT learn these ports, and also the addresses > of many other nodes, enabling various forms of attack propagation, > 3) The DHT application itself can be victim of DOS attacks, e.g. various > forms of name injection, query overload, response spoofing. > > In fact, solving such issues is an interesting challenge for end-to-end > researchers! > > -- Christian Huitema From anandk at ece.iisc.ernet.in Tue Feb 14 20:32:33 2006 From: anandk at ece.iisc.ernet.in (Anand Kunde) Date: Wed, 15 Feb 2006 10:02:33 +0530 (IST) Subject: [e2e] (no subject) Message-ID: <34357.10.32.20.12.1139977953.squirrel@unknown> Hello everybody, I would like to know about the following details in a UMTS(3G) wireless system.Please clarify my doubts. 1.Is it possible for a mobile to use multiple TCP connections simultaneously(file downlods)? 2.At the base station,incase of file downloads from the net(downlink),will the BS maintains seperate queues for different users or will use the same queue? 3.And for the case (1)(mobile using multiple TCPs simultaneously),will the BS maintains the same queue for downlink tx for all connections or different queues? If anybody knows ,please clarify my doubts. Regards Anand Kunde Research Student(MSc(Engg)) Performance Analysis Lab Department Of Electrical Communications Indian Institute Of Science Bangalore-560 012 India Email Id:anandk at ece.iisc.ernet.in anand.kunde at gmail.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From anandk at ece.iisc.ernet.in Tue Feb 14 20:32:55 2006 From: anandk at ece.iisc.ernet.in (Anand Kunde) Date: Wed, 15 Feb 2006 10:02:55 +0530 (IST) Subject: [e2e] doubt regarding queueing of packets at BS in a 3G wireless network. Message-ID: <34358.10.32.20.12.1139977975.squirrel@unknown> Hello everybody, I would like to know about the following details in a UMTS(3G) wireless system.Please clarify my doubts. 1.Is it possible for a mobile to use multiple TCP connections simultaneously(file downlods)? 2.At the base station,incase of file downloads from the net(downlink),will the BS maintains seperate queues for different users or will use the same queue? 3.And for the case (1)(mobile using multiple TCPs simultaneously),will the BS maintains the same queue for downlink tx for all connections or different queues? If anybody knows ,please clarify my doubts. Regards Anand Kunde Research Student(MSc(Engg)) Performance Analysis Lab Department Of Electrical Communications Indian Institute Of Science Bangalore-560 012 India Email Id:anandk at ece.iisc.ernet.in anand.kunde at gmail.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From touch at ISI.EDU Tue Feb 14 21:31:55 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 14 Feb 2006 21:31:55 -0800 Subject: [e2e] doubt regarding queueing of packets at BS in a 3G wireless network. In-Reply-To: <34358.10.32.20.12.1139977975.squirrel@unknown> References: <34358.10.32.20.12.1139977975.squirrel@unknown> Message-ID: <43F2BCCB.8020206@isi.edu> Anand, The current phrasing (below) sounds very much like a homework assignment, and would be off-topic for this list as such. Joe (as list admin) Anand Kunde wrote: > Hello everybody, > I would like to know about the following > details in a UMTS(3G) wireless system.Please clarify my doubts. > 1.Is it possible for a mobile to use multiple TCP > connections simultaneously(file downlods)? > > 2.At the base station,incase of file downloads from > the net(downlink),will the BS maintains seperate > queues for different users or will use the same queue? > > 3.And for the case (1)(mobile using multiple TCPs > simultaneously),will the BS maintains the same queue > for downlink tx for all connections or different > queues? > > > If anybody knows ,please clarify my doubts. > > > > > > > > Regards > Anand Kunde > Research Student(MSc(Engg)) > Performance Analysis Lab > Department Of Electrical Communications > Indian Institute Of Science > Bangalore-560 012 > India > Email Id:anandk at ece.iisc.ernet.in > anand.kunde at gmail.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060214/059f2133/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Wed Feb 15 01:00:04 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 15 Feb 2006 09:00:04 +0000 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: Message from "Christian Huitema" of "Tue, 14 Feb 2006 12:37:23 PST." Message-ID: In missive , "Christian Huitema" typed: >>> Jon Crowcroft wrote: >>> > um, i think you need to re-read about DHTs and consistent hashes >>> >>> What I was saying was that this variant won't work behind a NAT. I >>> mistook that from your initial post; I still consider it accurate, but >>> it may be off topic. >>Protecting DHT against DOS attacks is indeed a big issue. Consider: This is now orthogonal to what i was proposing, but is a good topic to discuss for sure... The issue for defending a consistent hash based overlay routes has received quite a lot of attention from folks like the MSR pastry group and bamboo/opendht and chord and others...and CAN Has some tricks too The whole point of P2P is that its load balanced and hard to DDoS as you have to attack multiple points rather than just one or a few servers, but you can try to attack the routing system Basically finger table or prefix schemes keep _multiple_ next neighbour entries - you have to do this in any P2P system because of chrun (nodes leave/turned off un-announced) - actually whether unstructured or structured; so if you take out a node, you dont break the P2P system at all - in fact you need to remove quite a few (I think both chord and can have been fairly extensively analyszed from this point. >>1) The nodes participating in the DHT need an open communication port >>which is ipso facto a target for DOS attacks, see above - you can take out a node, but not the net, easily - plus content can be replicated (and was - way back in the eternity system for example) >>2) The nodes observing the DHT learn these ports, and also the addresses >>of many other nodes, enabling various forms of attack propagation, This is a good point, and defending against this probavyl currently relies on the P2P just having a lot of distributed resource possibly compared to the attacker...(unless the attacker subverts the p2p nodes themselves in numbers- a pastry or kazaa based zombie organisation would be a fairly scary thing - ) >>3) The DHT application itself can be victim of DOS attacks, e.g. various >>forms of name injection, query overload, response spoofing. So lots of work has been done on integrity checking and reputation/recommendation and social re-enforcement schemes that limit this sort of damage - viz bittorrent etc etc... >>In fact, solving such issues is an interesting challenge for end-to-end >>researchers! Absolutely! Only 355 days til SIGCOMM 2007 deadline:) cheers jon From andras.veres at ericsson.com Wed Feb 15 08:17:48 2006 From: andras.veres at ericsson.com (=?iso-8859-1?Q?Andr=E1s_Veres_=28IJ/ETH=29?=) Date: Wed, 15 Feb 2006 17:17:48 +0100 Subject: [e2e] TCP over mobile networks: Are there any problems left? Message-ID: I would say yes and no. GPRS and UMTS spurious timeouts are not frequent because the estimated RTO is typically beyond the jitter induced by these technologies. And even if timeout kicks in, the bandwidth-delay product is not large, so speeding back does not take long time. Nevertheless, I would not simplify wireless "problems" solely to spurious timeouts or real losses. There are potentially issues in future wireless that are unique to wireless and as speeds go higher may become problems. Currently I would not say that there will be problems, but I have not seen any detailed analysis on this topic. What issues are there? Mobility: handoffs may become quite frequent, e.g., once a minute. When the host goes between cells or APs, it has to reconnect, which may have some bad consequences. For example, there may be an outage time, or the available capacity in the target cell may be drastically different from the originating cell due to different technology or simply due to different traffic in the cells. Imagine a mobile with a download rate of 100Mbps entering a cell with just 10Mbps free capacity. Mobility may become also an issue in the fixed transport network, because traffic flows may be rerouted to different paths during mobility. Capacity/coverage: In wired networks capacity changes are not typical. In wireless networks capacity is not constant, but change with time and place. Your WLAN connection may fluctuate quite heavily depending on how you place your hand or body... Today the access is the typical bottleneck (and the server side as second.) in DSL, but with wireless becoming more common, sharing between several people (1 - 100?) will also become common. So a congestion control protocol that is good alone on a high speed link, may not be so good on an access link shared by (1 - 100?) users. There have been some nice work on how TCP performs under dynamic conditions (at Stanford for example), and the results show quite mixed performance. I am missing very much a good, widely accepted evaluation metric of TCP goodness... Then we could have an agreed upon analysis method to use for wireless or fixed simulations and tell whether there are going to be serious problems or not. Andras >> This question may sound somewhat stupid, but after having read about quite a few claimed "problems" with TCP over mobile network, I?m finally not sure whether there exist any or not. As one example, the frequently discussed spurious timeouts turn out to be a myth, when we look at "TCP Spurious Timeout estimation in an operational GPRS/UMTS network" by Francesco Vacirca, Thomas Ziegler and Eduard Hasenleithner. I?m somewhat puzzled here. I read about alleged problems here in quite a few papers for years, but when I have a closer look at them, most of the alleged problems are not really sound. So, I tend to say provokingly: "TCP over mobile networks works just fine as it is. There are no known problems left." Is this true? Or am I wrong here? -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060215/c47b1b79/attachment-0001.html From touch at ISI.EDU Wed Feb 15 17:02:06 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 15 Feb 2006 17:02:06 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <43F3CF0E.7090104@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Crowcroft wrote: > In missive loy.ntdev.microsoft.com>, "Christian Huitema" typed: > > >>> Jon Crowcroft wrote: > >>> > um, i think you need to re-read about DHTs and consistent hashes > >>> > >>> What I was saying was that this variant won't work behind a NAT. I > >>> mistook that from your initial post; I still consider it accurate, but > >>> it may be off topic. > > >>Protecting DHT against DOS attacks is indeed a big issue. Consider: > > This is now orthogonal to what i was proposing, but is a good topic to > discuss for sure... > > The issue for defending a > consistent hash based overlay routes has received quite > a lot of attention from folks like the MSR pastry group > and bamboo/opendht and chord and others...and CAN Has some tricks too > > The whole point of P2P is that its load balanced and hard to DDoS as > you have to attack multiple points rather than just one or a few > servers, but you can try to attack the routing system You can attack it by looking up the same thing from everywhere; at some point, those messages will fan-in. I.e., a conventional DDoS attack maps just fine to a P2P. The only thing that saves your network is alternate path routing; P2Ps have this only to the extent that it's added. It's not a 'natural' property of a P2P network any more than it is of a conventional routing system, and the additions are very similar, and similarly orthogonal to the architecture. As to saving a node, you can replicate its contents, which again will help both systems; a conventional system uses DNS randomization or server farm tricks (L4 multipath) to distribute the load; a P2P, which runs at the app layer anyway, does this at the P2P layer - but again, it has to be added. I.e., there's no free ride here for DDOS. > Basically finger table or prefix schemes keep _multiple_ next > neighbour entries - you have to do this in any P2P system because of > chrun (nodes leave/turned off un-announced) - actually whether > unstructured or structured; so if you take out a node, you dont break > the P2P system at all - in fact you need to remove quite a few (I > think both chord and can have been fairly extensively analyszed from > this point. > > >>1) The nodes participating in the DHT need an open communication port > >>which is ipso facto a target for DOS attacks, > see above - you can take out a node, but not the net, easily - plus > content can be replicated (and was - way back in the eternity system > for example) That's true for existing routing too - DDOS takes out the node, not the net, unless the routing doesn't have diversity. FWIW ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD888OE5f5cImnZrsRAvhfAKCXPghAFPxn9EuN4j5NF4OuSufUxQCfcTUi 0VVELAdSgRyfgxb+Eb8hYgc= =OvDh -----END PGP SIGNATURE----- From jsj at ieee.org Wed Feb 15 17:23:42 2006 From: jsj at ieee.org (Scott Johnson) Date: Wed, 15 Feb 2006 20:23:42 -0500 Subject: [e2e] TCP Congestion Avoidance Message-ID: <43F3D41E.7070200@ieee.org> I was wondering if there was a feeling among the list members if the approximation for TCP throughput developed by Matthew Mathis, Jeffrey Semke, and Jamshid Mahdavi in their 1999 (I believe it was 1999) paper entitled "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm" is still valid? I am particulary curious if folks feel that it could be approximated as: throughput <= ~0.7 * MSS / (rtt * sqrt (packet_loss)). This representation came from a paper by Phl Dykstra titled Gigabit Ethernet Jumbo Frames ( http://sd.wareonearth.com/woe/jumbo.html ). The topic came up at work and I didn't know if , with the passage of time, people still feel it is valid. I would sincerely appreciate any comments. -- Regards, Scott Johnson jsj at ieee.org From weigengyu at hotmail.com Wed Feb 15 21:59:17 2006 From: weigengyu at hotmail.com (weigengyu) Date: Thu, 16 Feb 2006 13:59:17 +0800 Subject: [e2e] TCP over mobile networks: Are there any problems left? References: Message-ID: Re: [e2e] TCP over mobile networks: Are there any problems left? The mobility in a pico-cell based mobile networks affect the transmission rates and quality. This had proved in a PHS mobile networks. In PHS network, the terminal would not permit to move faster than 20kilometer, and one voice channel can support 64kbps digital transmission. It can be estimate that there is the limitation due to terminal handoff in wlan--IEEE802.11 based network, especially with more than 10M or 100M transmission rate. But I belive, researches or technical reports are required. Gengyu ----- Original Message ----- From: Andr?s Veres (IJ/ETH) To: end2end-interest at postel.org Sent: Thursday, February 16, 2006 12:17 AM Subject: Re: [e2e] TCP over mobile networks: Are there any problems left? Mobility: handoffs may become quite frequent, e.g., once a minute. When the host goes between cells or APs, it has to reconnect, which may have some bad consequences. For example, there may be an outage time, or the available capacity in the target cell may be drastically different from the originating cell due to different technology or simply due to different traffic in the cells. Imagine a mobile with a download rate of 100Mbps entering a cell with just 10Mbps free capacity. Mobility may become also an issue in the fixed transport network, because traffic flows may be rerouted to different paths during mobility. Andras -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060216/0b576fb6/attachment.html From detlef.bosau at web.de Thu Feb 16 04:42:49 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 16 Feb 2006 13:42:49 +0100 Subject: [e2e] TCP over mobile networks: Are there any problems left? References: Message-ID: <43F47349.D621E20C@web.de> > weigengyu wrote: > > > The mobility in a pico-cell based mobile networks affect the > transmission rates > and quality. This had proved in a PHS mobile networks. > In PHS network, the terminal would not permit to move faster than > 20kilometer, > and one voice channel can support 64kbps digital transmission. > Is this a scientific problem? Or is this a technological problem? Varying throughput rates per se are neither a scientific problem nor a problem at all: They are a property of the channel. Particularly TCP will send with the correct rate due to the ACK pacing mechanism. > It can be estimate that there is the limitation due to terminal > handoff in wlan--IEEE802.11 > based network, especially with more than 10M or 100M transmission > rate. Perhaps I should say that I?m primarily interested in cellular networks. And I don?t see any handoff problem for TCP there. I?m using my mobile phone for more than 10 years now - and for voice calls roaming is hidden that fine that I don?t even notice it. O.k., there is some interpolation stuff and error correction stuff, but I think the disconnect time is less then 0.1 s. I expect horizontal cell handovers to stay within this limits. O.k., then we have 0.1 s disconnect time. This might be inappropriate for some applications, but it is no real problem for TCP. In addition, there are lots of approaches like Freeze TCP or M-TCP (hopefully I don?t mix it up with MTCP ;-)) which address exactly this problem by slowing down the sender e.g. with a zero window. What I do not understand yet is: -Are there scheduling mechanisms like Proportional Fair etc. generally used in cellular networks? I read about this in UMTS 2000, but what about GPRs? -If so: What?s the reason for that? -If so: Are there consequences for TCP resulting from the scheduling mechanisms? (Thierry Klein addressed this topic for Proportional Fair in his Globecom 04 paper). Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From antonio.pinizzotto at iit.cnr.it Fri Feb 17 00:46:40 2006 From: antonio.pinizzotto at iit.cnr.it (Antonio Pinizzotto) Date: Fri, 17 Feb 2006 09:46:40 +0100 Subject: [e2e] TCP Delayed Ack Message-ID: <43F58D70.3070900@iit.cnr.it> Hello, everybody. Do you know about a way to disable the TCP Delayed Ack on Linux? (just for test purpose) Thanks. Antonio From baruch at ev-en.org Fri Feb 17 04:10:39 2006 From: baruch at ev-en.org (Baruch Even) Date: Fri, 17 Feb 2006 12:10:39 +0000 Subject: [e2e] TCP Delayed Ack In-Reply-To: <43F58D70.3070900@iit.cnr.it> References: <43F58D70.3070900@iit.cnr.it> Message-ID: <43F5BD3F.8090202@ev-en.org> Antonio Pinizzotto wrote: > > Hello, > everybody. > > Do you know about a way to disable the TCP Delayed Ack on Linux? > (just for test purpose) There is no switch in Linux to do that. I do have a patch for 2.6.6 that forces Linux to keep in quick-ack mode, effectively disabling delayed-acks. I do not know if it will work on later kernels, it should though with possibly small adjustments. Let me know if you want me to mail it to you. Baruch From imcdnzl at gmail.com Thu Feb 16 19:31:43 2006 From: imcdnzl at gmail.com (Ian McDonald) Date: Fri, 17 Feb 2006 16:31:43 +1300 Subject: [e2e] TCP Congestion Avoidance In-Reply-To: <43F3D41E.7070200@ieee.org> References: <43F3D41E.7070200@ieee.org> Message-ID: The most used current paper that I am aware of for Reno is: http://www.cs.iastate.edu/~cs610/Modeling_TCP_Throughput_Umass.pdf This is quoted in many RFCs. In particular look at equation 20. It has been clarified since slightly but I've lost the reference to that paper/ On 2/16/06, Scott Johnson wrote: > I was wondering if there was a feeling among the list members if the > approximation for TCP throughput developed by Matthew Mathis, Jeffrey > Semke, and Jamshid Mahdavi in their 1999 (I believe it was 1999) paper > entitled "The Macroscopic Behavior of the TCP Congestion Avoidance > Algorithm" is still valid? I am particulary curious if folks feel that > it could be approximated as: throughput <= ~0.7 * MSS / (rtt * sqrt > (packet_loss)). This representation came from a paper by Phl Dykstra > titled Gigabit Ethernet Jumbo Frames ( > http://sd.wareonearth.com/woe/jumbo.html ). > > The topic came up at work and I didn't know if , with the passage of > time, people still feel it is valid. I would sincerely appreciate any > comments. > > -- > > > Regards, > > Scott Johnson > > jsj at ieee.org > > -- Ian McDonald http://wand.net.nz/~iam4 WAND Network Research Group Department of Computer Science University of Waikato New Zealand From saikat at cs.cornell.edu Fri Feb 17 10:11:40 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Fri, 17 Feb 2006 13:11:40 -0500 Subject: [e2e] TCP Delayed Ack In-Reply-To: <43F5BD3F.8090202@ev-en.org> References: <43F58D70.3070900@iit.cnr.it> <43F5BD3F.8090202@ev-en.org> Message-ID: <1140199900.25497.37.camel@localhost.localdomain> On Fri, 2006-02-17 at 12:10 +0000, Baruch Even wrote: > Antonio Pinizzotto wrote: > > Do you know about a way to disable the TCP Delayed Ack on Linux? > > There is no switch in Linux to do that. Have you tried the TCP_NODELAY socket option that disables Nagle? There is also a TCP_QUICKACK socket option. Check the manpage for tcp(7) for details. cheers, -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060217/419a1326/attachment.bin From ljorgenson at apparentnetworks.com Fri Feb 17 10:15:14 2006 From: ljorgenson at apparentnetworks.com (Loki Jorgenson) Date: Fri, 17 Feb 2006 10:15:14 -0800 Subject: [e2e] Proxy servers and e2e performance Message-ID: Does anyone have any insights into the effects and impacts of proxy service implementation in e2e performance? Or even have a decent suggestion for a design guide w.r.t. proxies? This seems like an overlooked topic and I am having trouble finding anything relevant. A book or solid overview article would be ideal to provide an assessment of the state-of-the-art. To clarify, I am less interested in the details of proxy configuration and architecture and more interested in studies that have analyzed their impact on performance (possibly w.r.t. config and architecture). Any suggestions? Loki Jorgenson Chief Scientist Apparent Networks The Hudson House Suite 400 - 321 Water Street Vancouver, BC, Canada, V6B 1B8 e ljorgenson at ApparentNetworks.com t 604 433 2333 ext 105 f 604 433 2311 m 604 250-4642 w www.ApparentNetworks.com From svp+ at cs.cmu.edu Fri Feb 17 11:40:38 2006 From: svp+ at cs.cmu.edu (Swapnil V. Patil) Date: Fri, 17 Feb 2006 14:40:38 -0500 Subject: [e2e] Proxy servers and e2e performance In-Reply-To: References: Message-ID: <1140205238.29487.12.camel@gs5017.sp.cs.cmu.edu> > A book or solid overview article would be ideal to provide an assessment > of the state-of-the-art. > > To clarify, I am less interested in the details of proxy configuration > and architecture and more interested in studies that have analyzed their > impact on performance (possibly w.r.t. config and architecture). > See (Google for) for papers from/by: - Pei Cao - "Web Caching Workshop" (past proceedings) /* exact title of this workshop keeps changing */ - World Wide Web (WWW) Conference (past proceedings) -swapnil From savoric at ee.tu-berlin.de Mon Feb 20 00:26:37 2006 From: savoric at ee.tu-berlin.de (Michael Savoric) Date: Mon, 20 Feb 2006 09:26:37 +0100 (CET) Subject: [e2e] TCP over mobile networks: Are there any problems left? In-Reply-To: References: Message-ID: <57354.84.166.208.190.1140423997.squirrel@mail.tkn.tu-berlin.de> Hi, you can also look into my dissertation http://edocs.tu-berlin.de/diss/2004/savoric_michael.htm From detlef.bosau at web.de Mon Feb 20 08:05:01 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 20 Feb 2006 17:05:01 +0100 Subject: [e2e] TCP over mobile networks: Are there any problems left? In-Reply-To: <57354.84.166.208.190.1140423997.squirrel@mail.tkn.tu-berlin.de> References: <57354.84.166.208.190.1140423997.squirrel@mail.tkn.tu-berlin.de> Message-ID: <43F9E8AD.8090705@web.de> Michael Savoric wrote: > Hi, > you can also look into my dissertation > http://edocs.tu-berlin.de/diss/2004/savoric_michael.htm > Hm. I just looked at the summary (you TKN guys always write so big books :-) IIRC, Morten Schlager?s PhD thesis has more than 250 pages as well ;-) ) of your thesis. Question: Where exactly do you see the problem for mobile networks here? In fact, I have to think about sharing network information (I find the acronym "NIS" for Network Information Sharing somewhat unfortunate here because we should learn to use terms and acronyms with unique, unambigous semantics instead of introducing "polymorphism" in the world of three letter words...): Which amount of information shall be shared? How much status information must be kept on intermediate systems? Is the whole thing worth the effort? NB: To the best of my knowledge, the vast majority of e.g. TC flows are short termed flows, i.e. less then 20 packets. Must we keep information of this flows? O.k., let?s use statistical information then. Is this feasible? We often talk about "self similarity" - which means, _extremely_ drastically spoken, that useful statistical information does not exist, because what ever statistics you chose you cannot expect to have consistent (in the statistical sense) values. With respect to mobile networks, I think the question is, whether there exists adverse interactions between the mechanisms of a mobile network and e2e congestion control and e2e pacing. If these interactions do not exist, nothing is to be done. If there exist any interactions - and I?m still not fully convinced of this, but during the last week or so my attitude started to change when I started to have a closer look at the scheduling mechanisms used in 3G networks, the reasons for the use of scheduling and the consequences for upper layers, the solution to overcome them are quite simple: We would use splitting or spoofing techniques to hide the wireless network from the wirebound internet. (As you see, I only consider the wirebound internet with some mobile or cellular "leafs". I don?t consider TCP in MANETs.) However, before we consider solutions, perhaps compare different ones, we first should identify the problem. And until recently, will say until before a week or so, I was about to consider e.g. spurious timeouts an urban legend. Because I never saw a compelling discussion which convinced me of their existence. I know, there is a huge amount of papers on this matter and a huge amount of PhD theses. Particularly on spurious timeouts. Most of them start with or contain the allegation: "Spurious timeouts do exist." - Period. There is no proof, there is no consideration what could be the reason for SRTO, there are hundreds of pages with a solution looking for a perhaps non existent problem. Perhaps you could help me on this one with the "hiccup" tool that was hostet on the pages of your institue for years: What was the motivation for this? Delay spikes? What?s the origin of delay spikes? And this is not the question: "We observed them". First of all: irreproducible experiments are always interesting. But rarely helpful. Second: Wrong implementations exist. So, an observation is not necessarily a structural or scientific problem. It might indicate a buggy implementation as well. I started with the consideration of mobile networks about 6 years ago. And the more I think about them, the more I see that the vast majority of literature I read about them in a computer science context is not very convincing. There is a lot of alleged problems and solutions to them. But I still miss the "hard scientific stuff". Spoken more drastically: I don?t know, whether mobile / cellular networks are a research topic for computer scientists who deal with TCP. I don?t know whether there is any particularity in them, which cannot be dealt with with well proven and existing methods. At the moment, I have a look at scheduling issues on layer 2 and whether they affect upper layers. Perhaps, there is some interaction, perhaps there is none. Thierry Klein writes, he has observed one. We?ll see ;-) Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From dwing at cisco.com Mon Feb 20 13:22:00 2006 From: dwing at cisco.com (Dan Wing) Date: Mon, 20 Feb 2006 13:22:00 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43F0B13C.8080801@isi.edu> Message-ID: <079801c63663$b074baa0$c4f0200a@amer.cisco.com> (behind on my email - sorry for the delay.) > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch > Sent: Monday, February 13, 2006 8:18 AM > To: Jon Crowcroft > Cc: end2end-interest at postel.org > Subject: Re: [e2e] 100% NAT - a DoS proof internet > > So if we want to talk to a set of known people, we hash their > > identifier (name) to TIME. We then send to each other at that agreed > > time - no-one else can send to us or from us to them, and > > the hash key can be a shared secret.... > > How do you "send to each other"? > > You need to talk to a host behind a NAT. You need to reach the service > on that host that runs this DHTime protocol. You can have > more than one host behind the NAT. A NAT basically makes everything > behind it look like one host. > > There are two options: > > a. the host behind the NAT tries to reach the other host first > this works only if the 'other host' is NOT behind > a NAT, so we're out of luck > > b. you 'register' your host somewhere as owning a unique > way to demultiplex packets to it You can communicate with a host behind a NAT if that host tries to communicate with you first. This is how ICE (draft-ietf-mmusic-ice) functions. ICE's basic operation in this regard is this: 1. Each host learns its public IP address (ICE describes using STUN, RFC3489, for this; however you could use any other technique you might prefer such as Bonjour, UPnP, or whatever), 2. They exchange their public IP addresses with each other using a rendezvous protocol (ICE expects "SDP" is the rendezvous protocol; SDP is used by SIP which solves your (b)), and then 3. The hosts begin sending UDP packets to each other's public IP address. The NAT binding is opened when the first inside->outside packet is seen by the NAT, which causes a subsequent outside->inside packet to be NATted to the proper host. There is a similar technique that works with TCP when both hosts are behind unmodified, unconfigured NATs. If I recall correctly the NAT technique does rely on the nearly ubiquitious (but TCP violating) "stealth" NAT behavior (that is, the NAT has to simply drop unexpected TCP SYNs rather than respond with an ICMP error or a TCP RST). For an example of specifics please see draft-hoffman-behave-tcp-03.txt. -d > A DHT does both of these - (a) to reach a node somewhere else that is > NOT NAT'd first, then (b) to register in that infrastructure so other > nodes can find it using its node ID. > > Two killer questions: > > 1. if everything is NAT'd, how do you perform step (a)? > i.e., where is the first place you register? > > 2. (b) assumes hosts have unique node-IDs, but you > went through a lot of trouble to remove that property (NATs) > > for every reason you had a NAT in the base net, > why is it now acceptable to not NAT the node-IDs? > > - if you NAT node IDs, you're back where you started > > - if you're OK with not NAT'ing node IDs, why did you > NAT the base net? > i.e., non-NAT'd node IDs now become susceptible > to every message on the DHT > > > there you go...the details should be simple (apart from how you > > provide sufficiently accurate synchronized time without a globally > > reachable adddress betweewn the NTP servers, which, I admit, is > > probably a mite tricky - i guess you need to have them > agree a set of > > rough times or something:) > > Time, IMO, is the least of your concerns... > > Joe > > From touch at ISI.EDU Mon Feb 20 14:09:33 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 20 Feb 2006 14:09:33 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <079801c63663$b074baa0$c4f0200a@amer.cisco.com> References: <079801c63663$b074baa0$c4f0200a@amer.cisco.com> Message-ID: <43FA3E1D.4070404@isi.edu> Dan Wing wrote: > (behind on my email - sorry for the delay.) > >> -----Original Message----- >> From: end2end-interest-bounces at postel.org >> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch >> Sent: Monday, February 13, 2006 8:18 AM >> To: Jon Crowcroft >> Cc: end2end-interest at postel.org >> Subject: Re: [e2e] 100% NAT - a DoS proof internet >>> So if we want to talk to a set of known people, we hash their >>> identifier (name) to TIME. We then send to each other at that agreed >>> time - no-one else can send to us or from us to them, and >>> the hash key can be a shared secret.... >> How do you "send to each other"? >> >> You need to talk to a host behind a NAT. You need to reach the service >> on that host that runs this DHTime protocol. You can have >> more than one host behind the NAT. A NAT basically makes everything >> behind it look like one host. >> >> There are two options: >> >> a. the host behind the NAT tries to reach the other host first >> this works only if the 'other host' is NOT behind >> a NAT, so we're out of luck >> >> b. you 'register' your host somewhere as owning a unique >> way to demultiplex packets to it > > You can communicate with a host behind a NAT if that host tries to > communicate with you first. This is how ICE (draft-ietf-mmusic-ice) > functions. ICE's basic operation in this regard is this: > > 1. Each host learns its public IP address (ICE describes using STUN, > RFC3489, for this; however you could use any other technique you > might prefer such as Bonjour, UPnP, or whatever), You can't learn your public IP address without (a) or (b) above. > 2. They exchange their public IP addresses with each other using a > rendezvous protocol (ICE expects "SDP" is the rendezvous > protocol; SDP is used by SIP which solves your (b)), and then I don't need to 'solve' (b); it's trivial to design a protocol to do this. The point I'm making is that (a) or (b) is required. This repeats that point. In the absence of both (a) and (b), how is it solvable? (_that_ is the real question). Joe > 3. The hosts begin sending UDP packets to each other's public > IP address. The NAT binding is opened when the first > inside->outside packet is seen by the NAT, which causes a > subsequent outside->inside packet to be NATted to the > proper host. > > > There is a similar technique that works with TCP when both hosts are > behind unmodified, unconfigured NATs. If I recall correctly the NAT > technique does rely on the nearly ubiquitious (but TCP violating) > "stealth" NAT behavior (that is, the NAT has to simply drop unexpected > TCP SYNs rather than respond with an ICMP error or a TCP RST). For an > example of specifics please see draft-hoffman-behave-tcp-03.txt. > > -d > >> A DHT does both of these - (a) to reach a node somewhere else that is >> NOT NAT'd first, then (b) to register in that infrastructure so other >> nodes can find it using its node ID. >> >> Two killer questions: >> >> 1. if everything is NAT'd, how do you perform step (a)? >> i.e., where is the first place you register? >> >> 2. (b) assumes hosts have unique node-IDs, but you >> went through a lot of trouble to remove that property (NATs) >> >> for every reason you had a NAT in the base net, >> why is it now acceptable to not NAT the node-IDs? >> >> - if you NAT node IDs, you're back where you started >> >> - if you're OK with not NAT'ing node IDs, why did you >> NAT the base net? >> i.e., non-NAT'd node IDs now become susceptible >> to every message on the DHT >> >>> there you go...the details should be simple (apart from how you >>> provide sufficiently accurate synchronized time without a globally >>> reachable adddress betweewn the NTP servers, which, I admit, is >>> probably a mite tricky - i guess you need to have them >> agree a set of >>> rough times or something:) >> Time, IMO, is the least of your concerns... >> >> Joe >> >> From dwing at cisco.com Mon Feb 20 14:24:09 2006 From: dwing at cisco.com (Dan Wing) Date: Mon, 20 Feb 2006 14:24:09 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FA3E1D.4070404@isi.edu> Message-ID: <07ad01c6366c$5f7af7a0$c4f0200a@amer.cisco.com> > Dan Wing wrote: > > (behind on my email - sorry for the delay.) > > > >> -----Original Message----- > >> From: end2end-interest-bounces at postel.org > >> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch > >> Sent: Monday, February 13, 2006 8:18 AM > >> To: Jon Crowcroft > >> Cc: end2end-interest at postel.org > >> Subject: Re: [e2e] 100% NAT - a DoS proof internet > >>> So if we want to talk to a set of known people, we hash their > >>> identifier (name) to TIME. We then send to each other at > that agreed > >>> time - no-one else can send to us or from us to them, and > >>> the hash key can be a shared secret.... > >> How do you "send to each other"? > >> > >> You need to talk to a host behind a NAT. You need to reach > >> the service > >> on that host that runs this DHTime protocol. You can have > >> more than one host behind the NAT. A NAT basically makes > >> everything > >> behind it look like one host. > >> > >> There are two options: > >> > >> a. the host behind the NAT tries to reach the other host first > >> this works only if the 'other host' is NOT behind > >> a NAT, so we're out of luck > >> > >> b. you 'register' your host somewhere as owning a unique > >> way to demultiplex packets to it > > > > You can communicate with a host behind a NAT if that host tries to > > communicate with you first. This is how ICE (draft-ietf-mmusic-ice) > > functions. ICE's basic operation in this regard is this: > > > > 1. Each host learns its public IP address (ICE describes > > using STUN, > > RFC3489, for this; however you could use any other > > technique you > > might prefer such as Bonjour, UPnP, or whatever), > > You can't learn your public IP address without (a) or (b) above. > > > 2. They exchange their public IP addresses with each other using a > > rendezvous protocol (ICE expects "SDP" is the rendezvous > > protocol; SDP is used by SIP which solves your (b)), and then > > I don't need to 'solve' (b); it's trivial to design a protocol to do > this. The point I'm making is that (a) or (b) is required. > This repeats that point. > > In the absence of both (a) and (b), how is it solvable? (_that_ is the > real question). I must be misunderstanding. ICE (draft-ietf-mmusic-ice) describes how a bi-directional UDP stream can be established between two hosts behind their own NATs, like this: [host]--[NAT]-----[Internet]-----[NAT]--[host] -d > Joe > > > 3. The hosts begin sending UDP packets to each other's public > > IP address. The NAT binding is opened when the first > > inside->outside packet is seen by the NAT, which causes a > > subsequent outside->inside packet to be NATted to the > > proper host. > > > > > > There is a similar technique that works with TCP when both hosts are > > behind unmodified, unconfigured NATs. If I recall correctly the NAT > > technique does rely on the nearly ubiquitious (but TCP violating) > > "stealth" NAT behavior (that is, the NAT has to simply drop > unexpected > > TCP SYNs rather than respond with an ICMP error or a TCP > RST). For an > > example of specifics please see draft-hoffman-behave-tcp-03.txt. > > > > -d > > > >> A DHT does both of these - (a) to reach a node somewhere > else that is > >> NOT NAT'd first, then (b) to register in that > infrastructure so other > >> nodes can find it using its node ID. > >> > >> Two killer questions: > >> > >> 1. if everything is NAT'd, how do you perform step (a)? > >> i.e., where is the first place you register? > >> > >> 2. (b) assumes hosts have unique node-IDs, but you > >> went through a lot of trouble to remove that property (NATs) > >> > >> for every reason you had a NAT in the base net, > >> why is it now acceptable to not NAT the node-IDs? > >> > >> - if you NAT node IDs, you're back where you started > >> > >> - if you're OK with not NAT'ing node IDs, why did you > >> NAT the base net? > >> i.e., non-NAT'd node IDs now become susceptible > >> to every message on the DHT > >> > >>> there you go...the details should be simple (apart from how you > >>> provide sufficiently accurate synchronized time without a globally > >>> reachable adddress betweewn the NTP servers, which, I admit, is > >>> probably a mite tricky - i guess you need to have them > >> agree a set of > >>> rough times or something:) > >> Time, IMO, is the least of your concerns... > >> > >> Joe > >> > >> From touch at ISI.EDU Mon Feb 20 14:35:08 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 20 Feb 2006 14:35:08 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <07ad01c6366c$5f7af7a0$c4f0200a@amer.cisco.com> References: <07ad01c6366c$5f7af7a0$c4f0200a@amer.cisco.com> Message-ID: <43FA441C.1020203@isi.edu> Dan Wing wrote: ... >>>> There are two options: >>>> >>>> a. the host behind the NAT tries to reach the other host first >>>> this works only if the 'other host' is NOT behind >>>> a NAT, so we're out of luck >>>> >>>> b. you 'register' your host somewhere as owning a unique >>>> way to demultiplex packets to it >>> You can communicate with a host behind a NAT if that host tries to >>> communicate with you first. This is how ICE (draft-ietf-mmusic-ice) >>> functions. ICE's basic operation in this regard is this: >>> >>> 1. Each host learns its public IP address (ICE describes >>> using STUN, >>> RFC3489, for this; however you could use any other >>> technique you >>> might prefer such as Bonjour, UPnP, or whatever), >> You can't learn your public IP address without (a) or (b) above. >> >>> 2. They exchange their public IP addresses with each other using a >>> rendezvous protocol (ICE expects "SDP" is the rendezvous >>> protocol; SDP is used by SIP which solves your (b)), and then >> I don't need to 'solve' (b); it's trivial to design a protocol to do >> this. The point I'm making is that (a) or (b) is required. >> This repeats that point. >> >> In the absence of both (a) and (b), how is it solvable? (_that_ is the >> real question). > > I must be misunderstanding. ICE (draft-ietf-mmusic-ice) describes > how a bi-directional UDP stream can be established between two > hosts behind their own NATs, like this: > > [host]--[NAT]-----[Internet]-----[NAT]--[host] >From your description above: - each host learns its public IP address please describe how this happens if only the two hosts above participate - notably without using a service on a public IP host elsewhere STUN servers must reside on the public Internet to determine the public address of a NAT'd host - the hosts rendezvous that works only if both hosts know they want to talk with each other. when both are behind a NAT, that means a registry on a public server is required. ICE is one protocol for doing that, but it still requires a public server somewhere (i.e., the TURN server) You're quoting are two protocols that solve the trivial case; the problematic case is when you have NEITHER STUN or TURN servers on the public Internet available. Joe > > -d > >> Joe >> >>> 3. The hosts begin sending UDP packets to each other's public >>> IP address. The NAT binding is opened when the first >>> inside->outside packet is seen by the NAT, which causes a >>> subsequent outside->inside packet to be NATted to the >>> proper host. >>> >>> >>> There is a similar technique that works with TCP when both hosts are >>> behind unmodified, unconfigured NATs. If I recall correctly the NAT >>> technique does rely on the nearly ubiquitious (but TCP violating) >>> "stealth" NAT behavior (that is, the NAT has to simply drop >> unexpected >>> TCP SYNs rather than respond with an ICMP error or a TCP >> RST). For an >>> example of specifics please see draft-hoffman-behave-tcp-03.txt. >>> >>> -d >>> >>>> A DHT does both of these - (a) to reach a node somewhere >> else that is >>>> NOT NAT'd first, then (b) to register in that >> infrastructure so other >>>> nodes can find it using its node ID. >>>> >>>> Two killer questions: >>>> >>>> 1. if everything is NAT'd, how do you perform step (a)? >>>> i.e., where is the first place you register? >>>> >>>> 2. (b) assumes hosts have unique node-IDs, but you >>>> went through a lot of trouble to remove that property (NATs) >>>> >>>> for every reason you had a NAT in the base net, >>>> why is it now acceptable to not NAT the node-IDs? >>>> >>>> - if you NAT node IDs, you're back where you started >>>> >>>> - if you're OK with not NAT'ing node IDs, why did you >>>> NAT the base net? >>>> i.e., non-NAT'd node IDs now become susceptible >>>> to every message on the DHT >>>> >>>>> there you go...the details should be simple (apart from how you >>>>> provide sufficiently accurate synchronized time without a globally >>>>> reachable adddress betweewn the NTP servers, which, I admit, is >>>>> probably a mite tricky - i guess you need to have them >>>> agree a set of >>>>> rough times or something:) >>>> Time, IMO, is the least of your concerns... >>>> >>>> Joe >>>> >>>> From dwing at cisco.com Mon Feb 20 14:57:23 2006 From: dwing at cisco.com (Dan Wing) Date: Mon, 20 Feb 2006 14:57:23 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FA441C.1020203@isi.edu> Message-ID: <002001c63671$053372e0$c4f0200a@amer.cisco.com> > > I must be misunderstanding. ICE (draft-ietf-mmusic-ice) describes > > how a bi-directional UDP stream can be established between two > > hosts behind their own NATs, like this: > > > > [host]--[NAT]-----[Internet]-----[NAT]--[host] > > From your description above: > > - each host learns its public IP address > please describe how this happens if only > the two hosts above participate - notably > without using a service on a public IP host elsewhere Both Bonjour and UPnP provide existing mechanisms to learn your public IP address. Depending on how they're implemented, they can even work in a nested NAT scenario like: [host]--[NAT]--[NAT]-----[Internet] NSIS provides another technique to learn your public IP address. > STUN servers must reside on the public Internet > to determine the public address of a NAT'd host Yes, a STUN server on the Internet is the technique described by ICE. STUN is the only existing IETF protocol to learn your public IP address. NSIS isn't yet ready and Bonjour's NAT-PMP and UPnP aren't IETF protocols. A STUN server could be integrated with your NAT device, of course, and provide the same information as a public STUN server. This could also be implemented to work in a nested NAT scenario like I diagrammed above, as well. > - the hosts rendezvous > that works only if both hosts know they want > to talk with each other. when both are behind > a NAT, that means a registry on a public server > is required. Publicly-accessible server. The server could, itself, be behind a NAT, so long as it had some way of learning its public IP address and publishing its public IP address and port. > ICE is one protocol for doing that, > but it still requires a public server somewhere > (i.e., the TURN server) ICE does not require a TURN server. A TURN server's only function is to relay UDP media, and is only necessary if the NAT implementation creates a new UDP binding when the host communicates to a new remote host (such behavior is called 'symmetric NAT' in RFC3489. The behavior makes it impossible to rendezvous on the UDP port you learned via STUN. Bonjour- and UPnP-learned addresses wouldn't suffer from this problem.) > You're quoting are two protocols that solve the trivial case; the > problematic case is when you have NEITHER STUN or TURN servers on the > public Internet available. TURN isn't needed unless the NAT's implementation is defective. If you don't want to hit a public STUN server such as stun-server.org, you would have to use UPnP, Bonjour, or buy a NAT with a STUN server built in. -d > Joe > > > > > -d > > > >> Joe > >> > >>> 3. The hosts begin sending UDP packets to each other's public > >>> IP address. The NAT binding is opened when the first > >>> inside->outside packet is seen by the NAT, which causes a > >>> subsequent outside->inside packet to be NATted to the > >>> proper host. > >>> > >>> > >>> There is a similar technique that works with TCP when > both hosts are > >>> behind unmodified, unconfigured NATs. If I recall > correctly the NAT > >>> technique does rely on the nearly ubiquitious (but TCP violating) > >>> "stealth" NAT behavior (that is, the NAT has to simply drop > >> unexpected > >>> TCP SYNs rather than respond with an ICMP error or a TCP > >> RST). For an > >>> example of specifics please see draft-hoffman-behave-tcp-03.txt. > >>> > >>> -d > >>> > >>>> A DHT does both of these - (a) to reach a node somewhere > >> else that is > >>>> NOT NAT'd first, then (b) to register in that > >> infrastructure so other > >>>> nodes can find it using its node ID. > >>>> > >>>> Two killer questions: > >>>> > >>>> 1. if everything is NAT'd, how do you perform step (a)? > >>>> i.e., where is the first place you register? > >>>> > >>>> 2. (b) assumes hosts have unique node-IDs, but you > >>>> went through a lot of trouble to remove that property (NATs) > >>>> > >>>> for every reason you had a NAT in the base net, > >>>> why is it now acceptable to not NAT the node-IDs? > >>>> > >>>> - if you NAT node IDs, you're back where you started > >>>> > >>>> - if you're OK with not NAT'ing node IDs, why did you > >>>> NAT the base net? > >>>> i.e., non-NAT'd node IDs now become susceptible > >>>> to every message on the DHT > >>>> > >>>>> there you go...the details should be simple (apart from how you > >>>>> provide sufficiently accurate synchronized time without > a globally > >>>>> reachable adddress betweewn the NTP servers, which, I admit, is > >>>>> probably a mite tricky - i guess you need to have them > >>>> agree a set of > >>>>> rough times or something:) > >>>> Time, IMO, is the least of your concerns... > >>>> > >>>> Joe > >>>> > >>>> From touch at ISI.EDU Mon Feb 20 17:11:04 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 20 Feb 2006 17:11:04 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <002001c63671$053372e0$c4f0200a@amer.cisco.com> References: <002001c63671$053372e0$c4f0200a@amer.cisco.com> Message-ID: <43FA68A8.2050207@isi.edu> Hi, Dan, Dan Wing wrote: >>> I must be misunderstanding. ICE (draft-ietf-mmusic-ice) describes >>> how a bi-directional UDP stream can be established between two >>> hosts behind their own NATs, like this: >>> >>> [host]--[NAT]-----[Internet]-----[NAT]--[host] >> From your description above: >> >> - each host learns its public IP address >> please describe how this happens if only >> the two hosts above participate - notably >> without using a service on a public IP host elsewhere > > Both Bonjour and UPnP provide existing mechanisms to learn your > public IP address. Depending on how they're implemented, they > can even work in a nested NAT scenario like: > > [host]--[NAT]--[NAT]-----[Internet] > > NSIS provides another technique to learn your public IP address. > >> STUN servers must reside on the public Internet >> to determine the public address of a NAT'd host > > Yes, a STUN server on the Internet is the technique described > by ICE. STUN is the only existing IETF protocol to learn > your public IP address. NSIS isn't yet ready and Bonjour's > NAT-PMP and UPnP aren't IETF protocols. > > A STUN server could be integrated with your NAT device, of > course, and provide the same information as a public STUN > server. This could also be implemented to work in a nested > NAT scenario like I diagrammed above, as well. > >> - the hosts rendezvous >> that works only if both hosts know they want >> to talk with each other. when both are behind >> a NAT, that means a registry on a public server >> is required. > > Publicly-accessible server. The server could, itself, be behind > a NAT, so long as it had some way of learning its public IP address > and publishing its public IP address and port. How? That's the trick with ALL of these. Short of having a cooperating system in the public Internet or the equivalent (i.e., a friendly net manager, or omniscient deity), how? >> ICE is one protocol for doing that, >> but it still requires a public server somewhere >> (i.e., the TURN server) > > ICE does not require a TURN server. > > A TURN server's only function is to relay UDP media, and is > only necessary if the NAT implementation creates a new UDP > binding when the host communicates to a new remote host (such > behavior is called 'symmetric NAT' in RFC3489. The behavior > makes it impossible to rendezvous on the UDP port you learned > via STUN. Bonjour- and UPnP-learned addresses wouldn't suffer > from this problem.) Fine, but you still need the STUN server in the first place. >> You're quoting are two protocols that solve the trivial case; the >> problematic case is when you have NEITHER STUN or TURN servers on the >> public Internet available. > > TURN isn't needed unless the NAT's implementation is defective. > > If you don't want to hit a public STUN server such as stun-server.org, > you would have to use UPnP, Bonjour, or buy a NAT with a STUN server > built in. How would any of that help if all of those systems UPnP, Bonjour, or a NAT w/STUN inside) are behind NATs? The problem is that you cannot control whether you're stuffed behind a NAT - short of out-of-band agreement from your ISP. Once you are, none of these systems work. Joe From dwing at cisco.com Mon Feb 20 17:39:42 2006 From: dwing at cisco.com (Dan Wing) Date: Mon, 20 Feb 2006 17:39:42 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FA68A8.2050207@isi.edu> Message-ID: <006301c63687$b06f5910$c4f0200a@amer.cisco.com> > >> - the hosts rendezvous > >> that works only if both hosts know they want > >> to talk with each other. when both are behind > >> a NAT, that means a registry on a public server > >> is required. > > > > Publicly-accessible server. The server could, itself, be behind > > a NAT, so long as it had some way of learning its public IP address > > and publishing its public IP address and port. > > How? > > That's the trick with ALL of these. Short of having a > cooperating system in the public Internet or the equivalent > (i.e., a friendly net manager, or omniscient deity), how? If you don't want a rendezvous protocol a host could indicate its publicly-accessible IP address and UDP port via SRV DNS records. DNS is, of course, a public server with a registry. But even with NAT you need DNS, so I'm failing to grasp the nuance of your argument that requiring a registry dooms the original poster's proposal. > >> ICE is one protocol for doing that, > >> but it still requires a public server somewhere > >> (i.e., the TURN server) > > > > ICE does not require a TURN server. > > > > A TURN server's only function is to relay UDP media, and is > > only necessary if the NAT implementation creates a new UDP > > binding when the host communicates to a new remote host (such > > behavior is called 'symmetric NAT' in RFC3489. The behavior > > makes it impossible to rendezvous on the UDP port you learned > > via STUN. Bonjour- and UPnP-learned addresses wouldn't suffer > > from this problem.) > > Fine, but you still need the STUN server in the first place. You do need a way to learn your public IP address and UDP port. STUN is but one way to accomplish that. Bonjour and UPnP are two other ways, and Bonjour and UPnP do not require a STUN server on the Internet. Integrating a STUN server into the NAT itself is a way to avoid a STUN server on the Internet, too. > >> You're quoting are two protocols that solve the trivial case; the > >> problematic case is when you have NEITHER STUN or TURN > >> servers on the > >> public Internet available. > > > > TURN isn't needed unless the NAT's implementation is defective. > > > > If you don't want to hit a public STUN server such as > > stun-server.org, > > you would have to use UPnP, Bonjour, or buy a NAT with a STUN server > > built in. > > How would any of that help if all of those systems UPnP, > Bonjour, or a > NAT w/STUN inside) are behind NATs? > > The problem is that you cannot control whether you're stuffed behind a > NAT - short of out-of-band agreement from your ISP. Once you are, none > of these systems work. UPnP and Bonjour only work if you own and control the NAT, I agree. STUN will tell you your public IP address, even if the NAT is owned by and controlled by your evil ISP that has put you behind a huge NAT. But in order to do that I agree you would need to talk with a STUN server on the Internet (such as stun-server.org). Sorry for jumping into the thread -- I thought the problem you had raised is that two hosts, both behind their own NATs, could not communicate with each other. It seems I misunderstood. -d From touch at ISI.EDU Mon Feb 20 21:33:38 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 20 Feb 2006 21:33:38 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <006301c63687$b06f5910$c4f0200a@amer.cisco.com> References: <006301c63687$b06f5910$c4f0200a@amer.cisco.com> Message-ID: <43FAA632.9030009@isi.edu> Dan Wing wrote: >>>> - the hosts rendezvous >>>> that works only if both hosts know they want >>>> to talk with each other. when both are behind >>>> a NAT, that means a registry on a public server >>>> is required. >>> Publicly-accessible server. The server could, itself, be behind >>> a NAT, so long as it had some way of learning its public IP address >>> and publishing its public IP address and port. >> How? >> >> That's the trick with ALL of these. Short of having a >> cooperating system in the public Internet or the equivalent >> (i.e., a friendly net manager, or omniscient deity), how? > > If you don't want a rendezvous protocol a host could indicate > its publicly-accessible IP address and UDP port via SRV DNS > records. You seem to be under the impression that everything works if a server somewhere knows it's public address. I agree. The question I asked is "what if it DOES NOT?" > DNS is, of course, a public server with a registry. But > even with NAT you need DNS, so I'm failing to grasp the > nuance of your argument that requiring a registry dooms > the original poster's proposal. Even with NAT you need public IP addresses that are known and fixed - i.e., you need someone somewhere to run a server that isn't _arbitrarily_ NAT'd. Sure, a controlled, fixed NAT that you have the omniscient power to see the public IP address of works. However, consider the following: what if everything you want to talk with is NAT'd what if everything you own is NAT'd What if there is a public Internet, but you can't tell anyone there to help you? _that_ is the problem. I.e., NAT-alleviation assumes someone somewhere has control over a machine who can help you. It's IMPOSSIBLE to bootstrap NAT-alleviation without that assistance. WITH that assistance, you can get around things. However, in order to assume that anyone out there can help you, you MUST assume someone, somewhere who isn't under the influence of NATs. I.e., you can't find your way out of the rabbit hole with NATs alone. >>>> ICE is one protocol for doing that, >>>> but it still requires a public server somewhere >>>> (i.e., the TURN server) >>> ICE does not require a TURN server. >>> >>> A TURN server's only function is to relay UDP media, and is >>> only necessary if the NAT implementation creates a new UDP >>> binding when the host communicates to a new remote host (such >>> behavior is called 'symmetric NAT' in RFC3489. The behavior >>> makes it impossible to rendezvous on the UDP port you learned >>> via STUN. Bonjour- and UPnP-learned addresses wouldn't suffer >>> from this problem.) >> Fine, but you still need the STUN server in the first place. > > You do need a way to learn your public IP address and UDP port. > STUN is but one way to accomplish that. Bonjour and UPnP are two > other ways, and Bonjour and UPnP do not require a STUN server on > the Internet. > > Integrating a STUN server into the NAT itself is a way to avoid > a STUN server on the Internet, too. If I had control to integrate the STUN server into the NAT - which I typically don't control or sometimes even know is there - why would I bother? The problem with NAT's isn't the NAT's you control; it's the NATs you don't. You can't run a STUN server behind those to any utility. >>>> You're quoting are two protocols that solve the trivial case; the >>>> problematic case is when you have NEITHER STUN or TURN >>>> servers on the >>>> public Internet available. >>> TURN isn't needed unless the NAT's implementation is defective. >>> >>> If you don't want to hit a public STUN server such as >>> stun-server.org, >>> you would have to use UPnP, Bonjour, or buy a NAT with a STUN server >>> built in. >> How would any of that help if all of those systems UPnP, >> Bonjour, or a >> NAT w/STUN inside) are behind NATs? >> >> The problem is that you cannot control whether you're stuffed behind a >> NAT - short of out-of-band agreement from your ISP. Once you are, none >> of these systems work. > > UPnP and Bonjour only work if you own and control the NAT, I agree. They're not solutions then. > STUN will tell you your public IP address, even if the NAT is owned by > and controlled by your evil ISP that has put you behind a huge NAT. > But in order to do that I agree you would need to talk with a STUN > server on the Internet (such as stun-server.org). Again back to the same solution - the only way to make two NAT'd boxes talk to each other is with the assistance of another, non-NAT'd box. > Sorry for jumping into the thread -- I thought the problem you > had raised is that two hosts, both behind their own NATs, could > not communicate with each other. It seems I misunderstood. That is the problem; you keep adding things I didn't assume, i.e, you define away the problem. We agree that two NAT'd boxes can talk with the help of a non-NAT'd box. That's easy. Two NAT'd boxes alone cannot talk to each other. (and I assume NATs aren't under your own control because they that's the typical case). Joe From dwing at cisco.com Mon Feb 20 22:01:52 2006 From: dwing at cisco.com (Dan Wing) Date: Mon, 20 Feb 2006 22:01:52 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FAA632.9030009@isi.edu> Message-ID: <010201c636ac$50197bc0$c4f0200a@amer.cisco.com> > Dan Wing wrote: > >>>> - the hosts rendezvous > >>>> that works only if both hosts know they want > >>>> to talk with each other. when both are behind > >>>> a NAT, that means a registry on a public server > >>>> is required. > >>> Publicly-accessible server. The server could, itself, be behind > >>> a NAT, so long as it had some way of learning its public > IP address > >>> and publishing its public IP address and port. > >> How? > >> > >> That's the trick with ALL of these. Short of having a > >> cooperating system in the public Internet or the equivalent > >> (i.e., a friendly net manager, or omniscient deity), how? > > > > If you don't want a rendezvous protocol a host could indicate > > its publicly-accessible IP address and UDP port via SRV DNS > > records. > > You seem to be under the impression that everything works if a server > somewhere knows it's public address. I agree. > > The question I asked is "what if it DOES NOT?" > > > DNS is, of course, a public server with a registry. But > > even with NAT you need DNS, so I'm failing to grasp the > > nuance of your argument that requiring a registry dooms > > the original poster's proposal. > > Even with NAT you need public IP addresses that are known and fixed - > i.e., you need someone somewhere to run a server that isn't > _arbitrarily_ NAT'd. Sure, a controlled, fixed NAT that you have the > omniscient power to see the public IP address of works. > > However, consider the following: > > what if everything you want to talk with is NAT'd > > what if everything you own is NAT'd > > What if there is a public Internet, but you can't tell anyone there to > help you? > > _that_ is the problem. > > I.e., NAT-alleviation assumes someone somewhere has control over a > machine who can help you. It's IMPOSSIBLE to bootstrap NAT-alleviation > without that assistance. I fail to understand the distinction between the problem you're describing and the same problem without any NATs whatsoever. For example if I get a publicly routable IP address from my ISP and I want you to send me some packets, I need to somehow tell you that IP address. I might do that with DNS or via some other protocol (or SIP or Jabber). A fully NATted universe doesn't work, I agree. But it is possible for two NATted devices to exchange UDP (and TCP) packets without relaying those UDP (TCP) packets through some non-NATted device. > WITH that assistance, you can get around things. However, in order to > assume that anyone out there can help you, you MUST assume someone, > somewhere who isn't under the influence of NATs. Yes, of course. > I.e., you can't find your way out of the rabbit hole with NATs alone. Agreed. > >>>> ICE is one protocol for doing that, > >>>> but it still requires a public server somewhere > >>>> (i.e., the TURN server) > >>> ICE does not require a TURN server. > >>> > >>> A TURN server's only function is to relay UDP media, and is > >>> only necessary if the NAT implementation creates a new UDP > >>> binding when the host communicates to a new remote host (such > >>> behavior is called 'symmetric NAT' in RFC3489. The behavior > >>> makes it impossible to rendezvous on the UDP port you learned > >>> via STUN. Bonjour- and UPnP-learned addresses wouldn't suffer > >>> from this problem.) > >> Fine, but you still need the STUN server in the first place. > > > > You do need a way to learn your public IP address and UDP port. > > STUN is but one way to accomplish that. Bonjour and UPnP are two > > other ways, and Bonjour and UPnP do not require a STUN server on > > the Internet. > > > > Integrating a STUN server into the NAT itself is a way to avoid > > a STUN server on the Internet, too. > > If I had control to integrate the STUN server into the NAT - which I > typically don't control or sometimes even know is there - why would I > bother? > > The problem with NAT's isn't the NAT's you control; it's the NATs you > don't. You can't run a STUN server behind those to any utility. > > >>>> You're quoting are two protocols that solve the trivial case; the > >>>> problematic case is when you have NEITHER STUN or TURN > >>>> servers on the > >>>> public Internet available. > >>> TURN isn't needed unless the NAT's implementation is defective. > >>> > >>> If you don't want to hit a public STUN server such as > >>> stun-server.org, > >>> you would have to use UPnP, Bonjour, or buy a NAT with a > STUN server > >>> built in. > >> How would any of that help if all of those systems UPnP, > >> Bonjour, or a > >> NAT w/STUN inside) are behind NATs? > >> > >> The problem is that you cannot control whether you're > stuffed behind a > >> NAT - short of out-of-band agreement from your ISP. Once > you are, none > >> of these systems work. > > > > UPnP and Bonjour only work if you own and control the NAT, I agree. > > They're not solutions then. > > > STUN will tell you your public IP address, even if the NAT > is owned by > > and controlled by your evil ISP that has put you behind a > huge NAT. > > But in order to do that I agree you would need to talk with a STUN > > server on the Internet (such as stun-server.org). > > Again back to the same solution - the only way to make two NAT'd boxes > talk to each other is with the assistance of another, non-NAT'd box. > > > Sorry for jumping into the thread -- I thought the problem you > > had raised is that two hosts, both behind their own NATs, could > > not communicate with each other. It seems I misunderstood. > > That is the problem; you keep adding things I didn't assume, i.e, you > define away the problem. > > We agree that two NAT'd boxes can talk with the help of a > non-NAT'd box. > That's easy. > > Two NAT'd boxes alone cannot talk to each other. > > (and I assume NATs aren't under your own control because they > that's the typical case). At Starbucks or as a subscriber in S. Korea or China, I agree it's typical. -d From alokdube at hotPOP.com Mon Feb 20 22:22:32 2006 From: alokdube at hotPOP.com (alok) Date: Tue, 21 Feb 2006 11:52:32 +0530 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <07ad01c6366c$5f7af7a0$c4f0200a@amer.cisco.com> Message-ID: <20060221062234.230BF1A01EC@smtp-1.hotpop.com> Any chances that NATs will no longer be stateful? -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Dan Wing Sent: Tuesday, February 21, 2006 3:54 AM To: 'Joe Touch' Cc: 'Jon Crowcroft'; end2end-interest at postel.org Subject: Re: [e2e] 100% NAT - a DoS proof internet > Dan Wing wrote: > > (behind on my email - sorry for the delay.) > > > >> -----Original Message----- > >> From: end2end-interest-bounces at postel.org > >> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch > >> Sent: Monday, February 13, 2006 8:18 AM > >> To: Jon Crowcroft > >> Cc: end2end-interest at postel.org > >> Subject: Re: [e2e] 100% NAT - a DoS proof internet > >>> So if we want to talk to a set of known people, we hash their > >>> identifier (name) to TIME. We then send to each other at > that agreed > >>> time - no-one else can send to us or from us to them, and > >>> the hash key can be a shared secret.... > >> How do you "send to each other"? > >> > >> You need to talk to a host behind a NAT. You need to reach > >> the service > >> on that host that runs this DHTime protocol. You can have > >> more than one host behind the NAT. A NAT basically makes > >> everything > >> behind it look like one host. > >> > >> There are two options: > >> > >> a. the host behind the NAT tries to reach the other host first > >> this works only if the 'other host' is NOT behind > >> a NAT, so we're out of luck > >> > >> b. you 'register' your host somewhere as owning a unique > >> way to demultiplex packets to it > > From touch at ISI.EDU Mon Feb 20 22:36:26 2006 From: touch at ISI.EDU (Joe Touch) Date: Mon, 20 Feb 2006 22:36:26 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <010201c636ac$50197bc0$c4f0200a@amer.cisco.com> References: <010201c636ac$50197bc0$c4f0200a@amer.cisco.com> Message-ID: <43FAB4EA.5020009@isi.edu> Dan Wing wrote: ... > I fail to understand the distinction between the problem you're > describing and the same problem without any NATs whatsoever. For example > if I get a publicly routable IP address from my ISP and I want you to > send me some packets, I need to somehow tell you that IP address. I > might do that with DNS or via some other protocol (or SIP or Jabber). Without NATs, you need: my IP address the port I run the service on I can run services that will accept incoming calls from anyone on that port. With NATs, I need to know YOU are calling be somehow, so that I can do something to trigger the NAT upstream from me ("my" NAT, though I typically don't 'control' it except by sending packets that trigger associations). The only way to do that is via a server on the public Internet (short of a telephone, which can cheat in any coordination system). I.e., a NAT'd Internet is an incomplete architecture; it cannot usefully exist without non-NAT'd servers. > A fully NATted universe doesn't work, I agree. But it is possible for > two NATted devices to exchange UDP (and TCP) packets without relaying > those UDP (TCP) packets through some non-NATted device. They don't need to relay, but they do need the non-NAT'd device to register and exchange information. That's not the same as what a DNS does; a DNS just converts a name to an address; there's no 'exchange' of information between endpoints; the DNS isn't needed so that I know you will be calling me and act accordingly. ... >> Two NAT'd boxes alone cannot talk to each other. >> >> (and I assume NATs aren't under your own control because they >> that's the typical case). > > At Starbucks or as a subscriber in S. Korea or China, I agree it's typical. As a cable Internet subscriber in the US, too. Same for some DSL subscribers as well. It's not just a road-warrior or controlled-Internet problem. Joe From baruch at ev-en.org Tue Feb 21 04:15:08 2006 From: baruch at ev-en.org (Baruch Even) Date: Tue, 21 Feb 2006 12:15:08 +0000 Subject: [e2e] TCP Delayed Ack In-Reply-To: <1140199900.25497.37.camel@localhost.localdomain> References: <43F58D70.3070900@iit.cnr.it> <43F5BD3F.8090202@ev-en.org> <1140199900.25497.37.camel@localhost.localdomain> Message-ID: <43FB044C.40105@ev-en.org> Saikat Guha wrote: > On Fri, 2006-02-17 at 12:10 +0000, Baruch Even wrote: > >>Antonio Pinizzotto wrote: >> >>>Do you know about a way to disable the TCP Delayed Ack on Linux? >> >>There is no switch in Linux to do that. > > > Have you tried the TCP_NODELAY socket option that disables Nagle? There > is also a TCP_QUICKACK socket option. > > Check the manpage for tcp(7) for details. I didn't notice this option but it still wouldn't solve the issue of completely disabling delayed-acks. It might be useful to an application that for some reason wants to force acks, it's not so useful for experiments where you want to completely avoid delayed-acks. The manpage says the effect is temporary and so it also seems from the code. Baruch From touch at ISI.EDU Tue Feb 21 08:26:51 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 21 Feb 2006 08:26:51 -0800 Subject: [e2e] TCP Delayed Ack In-Reply-To: <43FB044C.40105@ev-en.org> References: <43F58D70.3070900@iit.cnr.it> <43F5BD3F.8090202@ev-en.org> <1140199900.25497.37.camel@localhost.localdomain> <43FB044C.40105@ev-en.org> Message-ID: <43FB3F4B.8030901@isi.edu> Baruch Even wrote: > Saikat Guha wrote: >> On Fri, 2006-02-17 at 12:10 +0000, Baruch Even wrote: >> >>> Antonio Pinizzotto wrote: >>> >>>> Do you know about a way to disable the TCP Delayed Ack on Linux? >>> There is no switch in Linux to do that. >> >> Have you tried the TCP_NODELAY socket option that disables Nagle? That addresses how data is (or is not) aggregated at the sender to avoid more than one outstanding (unack'd) partial segment. It doesn't deal with the ACKs. >> There >> is also a TCP_QUICKACK socket option. >> >> Check the manpage for tcp(7) for details. > > I didn't notice this option but it still wouldn't solve the issue of > completely disabling delayed-acks. > > It might be useful to an application that for some reason wants to force > acks, it's not so useful for experiments where you want to completely > avoid delayed-acks. The manpage says the effect is temporary and so it > also seems from the code. Why is the application forcing ACKs? What's the utility, other than to trick the other side to open its window faster than recommended? Joe From dpreed at reed.com Tue Feb 21 09:04:24 2006 From: dpreed at reed.com (David P. Reed) Date: Tue, 21 Feb 2006 12:04:24 -0500 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <20060221062234.230BF1A01EC@smtp-1.hotpop.com> References: <20060221062234.230BF1A01EC@smtp-1.hotpop.com> Message-ID: <43FB4818.8070507@reed.com> alok wrote: >Any chances that NATs will no longer be stateful? > > The danger is the other direction - every vendor and his brother wants to put state into the relay nodes (routers, firewalls) because they think that blocking communcations is the route to power (for their version of "good") over the Internet. The current craze in "communications economics" is the argument that no sustainable business model can support deployment of expensive routers unless those routers decode and understand every bit of every packet and determine how much to charge for each bit. "If only we can block all choice in communications, everybody will be perfectly safe" is how I paraphrase (in admittedly hyperbolic form) about 99% of the security "experts" on the planet already. And now we have the self described "economics experts" suggesting blocking as a way to build revenues. This is a vicious recursive cycle, because more stateful inspection and analysis just increases the investment and adds points of vulnerability to "attack". So it seems inevitable that we will end up with the perfect, 100% unconnected Internet of 2010. (innovation also goes out the window, but I think the mere trend towards disconnection has already pushed most of the innovators away, because they look farther down the road and see the problems). From baruch at ev-en.org Tue Feb 21 09:15:14 2006 From: baruch at ev-en.org (Baruch Even) Date: Tue, 21 Feb 2006 17:15:14 +0000 Subject: [e2e] TCP Delayed Ack In-Reply-To: <43FB3F4B.8030901@isi.edu> References: <43F58D70.3070900@iit.cnr.it> <43F5BD3F.8090202@ev-en.org> <1140199900.25497.37.camel@localhost.localdomain> <43FB044C.40105@ev-en.org> <43FB3F4B.8030901@isi.edu> Message-ID: <43FB4AA2.5050908@ev-en.org> Joe Touch wrote: > > Baruch Even wrote: > >>Saikat Guha wrote: >> >>>On Fri, 2006-02-17 at 12:10 +0000, Baruch Even wrote: >>>There >>>is also a TCP_QUICKACK socket option. >>> >>>Check the manpage for tcp(7) for details. >> >>I didn't notice this option but it still wouldn't solve the issue of >>completely disabling delayed-acks. >> >>It might be useful to an application that for some reason wants to force >>acks, it's not so useful for experiments where you want to completely >>avoid delayed-acks. The manpage says the effect is temporary and so it >>also seems from the code. > > > Why is the application forcing ACKs? What's the utility, other than to > trick the other side to open its window faster than recommended? I have no idea, which is why I used "might", the original point was for testing purposes and not normal operation. I can't offhand think of a real use of this for an application so I can't say I understand the reasoning of providing this option in the first place. Baruch From touch at ISI.EDU Tue Feb 21 13:23:32 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 21 Feb 2006 13:23:32 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <20060221062234.230BF1A01EC@smtp-1.hotpop.com> References: <20060221062234.230BF1A01EC@smtp-1.hotpop.com> Message-ID: <43FB84D4.60404@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 alok wrote: > Any chances that NATs will no longer be stateful? What's a stateless NAT? Just a firewall; it can't rewrite packets without state ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD+4TUE5f5cImnZrsRAtPIAKCBhc/ZPVhuq1+W/UIUpxJLJVhE3wCg2DS8 08X9DkcLjeHL6/j6yjHU4DU= =ER75 -----END PGP SIGNATURE----- From Jon.Crowcroft at cl.cam.ac.uk Tue Feb 21 14:58:41 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 21 Feb 2006 22:58:41 +0000 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: Message from Joe Touch of "Tue, 21 Feb 2006 13:23:32 PST." <43FB84D4.60404@isi.edu> Message-ID: glib. a nat could keep an algorithmic state variable but not maintain an externally detectable mapping from localt o globalraeachable adress (read my orignal email in this thread) OR it could keep state about actual e2e flows. completely different things In missive <43FB84D4.60404 at isi.edu>, Joe Touch typed: >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >> >> >>alok wrote: >>> Any chances that NATs will no longer be stateful? >> >>What's a stateless NAT? >> >>Just a firewall; it can't rewrite packets without state ;-) >> >>Joe >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.2.4 (MingW32) >>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org >> >>iD8DBQFD+4TUE5f5cImnZrsRAtPIAKCBhc/ZPVhuq1+W/UIUpxJLJVhE3wCg2DS8 >>08X9DkcLjeHL6/j6yjHU4DU= >>=ER75 >>-----END PGP SIGNATURE----- cheers jon From touch at ISI.EDU Tue Feb 21 15:08:15 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 21 Feb 2006 15:08:15 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: Message-ID: <43FB9D5F.2010307@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Crowcroft wrote: > glib. > > a nat could keep an algorithmic state variable but not maintain an externally detectable > mapping from localt o globalraeachable adress (read my orignal email in this thread) > OR > it could keep state about actual e2e flows. Sure. > completely different things Except that state is state ;-) I read the suggestion as "stateless", not "avoiding explicit per-connection state". Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD+51eE5f5cImnZrsRAgeeAKCWor8l1sJTDhc6ysBOyNjZWTFQcACgkybK QJt6KNgOvW2mUZ1kirK00GI= =PCIW -----END PGP SIGNATURE----- From alokdube at hotPOP.com Tue Feb 21 21:49:14 2006 From: alokdube at hotPOP.com (alok) Date: Wed, 22 Feb 2006 11:19:14 +0530 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FB9D5F.2010307@isi.edu> Message-ID: <20060222054913.218AA1A067D@smtp-1.hotpop.com> Hi, Well, I meant something on the lines of modifying send() and recv () in the sockets as: Send($remote_servername,"foo bar") Instead of: Send($remote_ip,"foo bar") Always make associations based on name rather than IP. Of course it means one would have to modify every stack out there, but things like skype etc could simply embed the method into their dlls etc when installed. -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch Sent: Wednesday, February 22, 2006 4:38 AM To: Jon Crowcroft Cc: alok; end2end-interest at postel.org Subject: Re: [e2e] 100% NAT - a DoS proof internet -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Crowcroft wrote: > glib. > > a nat could keep an algorithmic state variable but not maintain an externally detectable > mapping from localt o globalraeachable adress (read my orignal email in this thread) > OR > it could keep state about actual e2e flows. Sure. > completely different things Except that state is state ;-) I read the suggestion as "stateless", not "avoiding explicit per-connection state". Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD+51eE5f5cImnZrsRAgeeAKCWor8l1sJTDhc6ysBOyNjZWTFQcACgkybK QJt6KNgOvW2mUZ1kirK00GI= =PCIW -----END PGP SIGNATURE----- From touch at ISI.EDU Tue Feb 21 22:07:21 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 21 Feb 2006 22:07:21 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <20060222054913.218AA1A067D@smtp-1.hotpop.com> References: <20060222054913.218AA1A067D@smtp-1.hotpop.com> Message-ID: <43FBFF99.8090105@isi.edu> Since that's basically what we already do in many apps, how would this help? It's not enough to do that lookup in the endsystems, it has to happen along the path, i.e., those IDs need to be in the packets. However, that just invites NA(P)T designers to evolve to NAPNT (add name translation). Yes, there are many ways to define away the problem: - NAT host to NAT host using a non-NAT host somewhere which won't exist if NATs are pervasive - NAT host to NAT host using a non-translated ID which means at least one of the hosts is not NAT'd (not 'translated ID') anymore Joe alok wrote: > Hi, > > Well, I meant something on the lines of modifying send() and recv () in the > sockets as: > > Send($remote_servername,"foo bar") > > Instead of: > > Send($remote_ip,"foo bar") > > Always make associations based on name rather than IP. > > Of course it means one would have to modify every stack out there, but > things like skype etc could simply embed the method into their dlls etc when > installed. > > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch > Sent: Wednesday, February 22, 2006 4:38 AM > To: Jon Crowcroft > Cc: alok; end2end-interest at postel.org > Subject: Re: [e2e] 100% NAT - a DoS proof internet > > > > Jon Crowcroft wrote: >>> glib. >>> >>> a nat could keep an algorithmic state variable but not maintain an > externally detectable >>> mapping from localt o globalraeachable adress (read my orignal email in > this thread) >>> OR >>> it could keep state about actual e2e flows. > > Sure. > >>> completely different things > > Except that state is state ;-) I read the suggestion as "stateless", not > "avoiding explicit per-connection state". > > Joe From alokdube at hotPOP.com Tue Feb 21 22:18:48 2006 From: alokdube at hotPOP.com (alok) Date: Wed, 22 Feb 2006 11:48:48 +0530 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FBFF99.8090105@isi.edu> Message-ID: <20060222061849.3D1D31A1326@smtp-1.hotpop.com> Yes but I do not understand why there is a double association between a "$who and $where" For example if I wish to talk to "Tim" via my cell phone, I would simply look for the name "Tim" It would also need a change in the way end hosts make associations as of date, Last I checked, sockets use "IPs" to identify end points. It does not have a default "gethostbyname()" in it. Back in the dial up days I remember I used to get a nice name as: Ppp1.ispras.myisp.com In more modern DSL days, simply giving my name street address/my telephone directory entry as my port identifier (we get our DSL over our POTS) would not be so bad would it? But would any OS stack out there support this sort of a transaction, based completely on "$who-->send data" instead of the recursive "$who-->$where and then send data"? -----Original Message----- From: Joe Touch [mailto:touch at ISI.EDU] Sent: Wednesday, February 22, 2006 11:37 AM To: alok Cc: 'Jon Crowcroft'; end2end-interest at postel.org Subject: Re: [e2e] 100% NAT - a DoS proof internet Since that's basically what we already do in many apps, how would this help? It's not enough to do that lookup in the endsystems, it has to happen along the path, i.e., those IDs need to be in the packets. However, that just invites NA(P)T designers to evolve to NAPNT (add name translation). Yes, there are many ways to define away the problem: - NAT host to NAT host using a non-NAT host somewhere which won't exist if NATs are pervasive - NAT host to NAT host using a non-translated ID which means at least one of the hosts is not NAT'd (not 'translated ID') anymore Joe alok wrote: > Hi, > > Well, I meant something on the lines of modifying send() and recv () in the > sockets as: > > Send($remote_servername,"foo bar") > > Instead of: > > Send($remote_ip,"foo bar") > > Always make associations based on name rather than IP. > > Of course it means one would have to modify every stack out there, but > things like skype etc could simply embed the method into their dlls etc when > installed. > > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org] On Behalf Of Joe Touch > Sent: Wednesday, February 22, 2006 4:38 AM > To: Jon Crowcroft > Cc: alok; end2end-interest at postel.org > Subject: Re: [e2e] 100% NAT - a DoS proof internet > > > > Jon Crowcroft wrote: >>> glib. >>> >>> a nat could keep an algorithmic state variable but not maintain an > externally detectable >>> mapping from localt o globalraeachable adress (read my orignal email in > this thread) >>> OR >>> it could keep state about actual e2e flows. > > Sure. > >>> completely different things > > Except that state is state ;-) I read the suggestion as "stateless", not > "avoiding explicit per-connection state". > > Joe From touch at ISI.EDU Tue Feb 21 23:22:48 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 21 Feb 2006 23:22:48 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <20060222061849.3D1D31A1326@smtp-1.hotpop.com> References: <20060222061849.3D1D31A1326@smtp-1.hotpop.com> Message-ID: <43FC1148.2060003@isi.edu> alok wrote: > Yes but I do not understand why there is a double association between a > "$who and $where" > > For example if I wish to talk to "Tim" via my cell phone, I would simply > look for the name "Tim" > > It would also need a change in the way end hosts make associations as of > date, > Last I checked, sockets use "IPs" to identify end points. It does not have a > default "gethostbyname()" in it. It's trivial to write a new "sendbyname" and embed gethostbyname in it. > Back in the dial up days I remember I used to get a nice name as: > > Ppp1.ispras.myisp.com > > In more modern DSL days, simply giving my name street address/my telephone > directory entry as my port identifier (we get our DSL over our POTS) would > not be so bad would it? > > But would any OS stack out there support this sort of a transaction, based > completely on "$who-->send data" instead of the recursive "$who-->$where and > then send data"? The OS isn't what needs to support it; the name needs to go in the IP packet. Which means routing on DNS names. See TRIAD. With respect to NATs, you're just asking to have names rewritten; this doesn't solve anything. Joe From saikat at cs.cornell.edu Wed Feb 22 00:32:09 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Wed, 22 Feb 2006 03:32:09 -0500 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FBFF99.8090105@isi.edu> References: <20060222054913.218AA1A067D@smtp-1.hotpop.com> <43FBFF99.8090105@isi.edu> Message-ID: <1140597129.31192.14.camel@localhost.localdomain> On Tue, 2006-02-21 at 22:07 -0800, Joe Touch wrote: > IDs need to be in the packets. However, that > just invites NA(P)T designers to evolve to NAPNT (add name translation). NATs (not counting firewalls) are used to extend the IPv4 address space. The address space for "names" is infinite. Is there a motivation behind designing or deploying name-translation devices? -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060222/38c156e7/attachment.bin From saikat at cs.cornell.edu Wed Feb 22 00:52:04 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Wed, 22 Feb 2006 03:52:04 -0500 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FAB4EA.5020009@isi.edu> References: <010201c636ac$50197bc0$c4f0200a@amer.cisco.com> <43FAB4EA.5020009@isi.edu> Message-ID: <1140598324.31192.34.camel@localhost.localdomain> On Mon, 2006-02-20 at 22:36 -0800, Joe Touch wrote: > Without NATs, you need: > my IP address > the port I run the service on Indeed. As you suggest, lets assume there is a service that allows you somehow publish your IP address and port, which may be assigned dynamically by DHCP. +------ request ------+ V | [You] -- publish --> [Service] -- response --> [Me] > With NATs, I need to know YOU are calling be somehow, so that I can do > something to trigger the NAT upstream from me Also true. Simply change the service above to notify you when someone wants to contact you. +------ request ------+ V | [You] -- publish --> [Service] -- response --> [Me] A | +----- notify ---------+ > The only way to do that is via a server on the public Internet (short of > a telephone, which can cheat in any coordination system). The service doesn't have to be "on" the public internet, but rather accessible from the public Internet. In particular, the service can run behind a NAT that the service provider controls. The service provider configures the NAT to forward inbound queries to the correct private address. > I.e., a NAT'd Internet is an incomplete architecture; it cannot usefully > exist without non-NAT'd servers. Certainly, this service above would have to be part of the architecture to complete it. Just as DNS is now a part of the IP architecture. > That's not the same as what a DNS > does; a DNS just converts a name to an address; there's no 'exchange' of > information between endpoints; the DNS isn't needed so that I know you > will be calling me and act accordingly. Correct -- this is not what DNS does; this is what SIP does. In the IP-world, I need to know where to find you, so I use DNS. In the NAT-world, you need to know when someone wants to find you, so they use SIP. cheers, -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060222/a03bfb8a/attachment.bin From alokdube at hotPOP.com Wed Feb 22 00:57:19 2006 From: alokdube at hotPOP.com (alok) Date: Wed, 22 Feb 2006 14:27:19 +0530 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FC1148.2060003@isi.edu> Message-ID: <20060222085720.6477C1A0214@smtp-1.hotpop.com> > > But would any OS stack out there support this sort of a transaction, based > completely on "$who-->send data" instead of the recursive "$who-->$where and > then send data"? The OS isn't what needs to support it; the name needs to go in the IP packet. Which means routing on DNS names. See TRIAD. With respect to NATs, you're just asking to have names rewritten; this doesn't solve anything. => yes like TRIAD, except that it works differently when I have multiple NATs. It tends to "go up" and come down the same way. Take for example: (assuming all nodes are triad nodes) PC1--node1----node2--Node3--PC2 | | | | +----Node4---Node5--node6---+ If PC1 connects to PC2 via NAT1-NaT2-Nat3, PC2 is constrained to reply via NAT3-Nat2-Nat1. A bit different from the way the internet behaves today, is it not? I may have xMb uplink via node1 but a 10xMb downlink via node4. It may not matter if the NAT is close to the edge PC but it does matter as he NAT moves further up in the provider network, or at least it did when I used to try installing web caches. From touch at ISI.EDU Wed Feb 22 07:32:07 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 22 Feb 2006 07:32:07 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <1140597129.31192.14.camel@localhost.localdomain> References: <20060222054913.218AA1A067D@smtp-1.hotpop.com> <43FBFF99.8090105@isi.edu> <1140597129.31192.14.camel@localhost.localdomain> Message-ID: <43FC83F7.3020902@isi.edu> Saikat Guha wrote: > On Tue, 2006-02-21 at 22:07 -0800, Joe Touch wrote: >> IDs need to be in the packets. However, that >> just invites NA(P)T designers to evolve to NAPNT (add name translation). > > NATs (not counting firewalls) are used to extend the IPv4 address space. > The address space for "names" is infinite. Is there a motivation behind > designing or deploying name-translation devices? NATs make everything behind them look like one host. That hides the topology of an enterprise, and defeats incoming services (the latter exactly what we're trying to undo). Some people want them for those two reasons. Joe From touch at ISI.EDU Wed Feb 22 07:39:14 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 22 Feb 2006 07:39:14 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <1140598324.31192.34.camel@localhost.localdomain> References: <010201c636ac$50197bc0$c4f0200a@amer.cisco.com> <43FAB4EA.5020009@isi.edu> <1140598324.31192.34.camel@localhost.localdomain> Message-ID: <43FC85A2.3050303@isi.edu> Saikat Guha wrote: > On Mon, 2006-02-20 at 22:36 -0800, Joe Touch wrote: >> Without NATs, you need: >> my IP address >> the port I run the service on > > Indeed. As you suggest, lets assume there is a service that allows you > somehow publish your IP address and port, which may be assigned > dynamically by DHCP. If you had a place to publish them, that place would need to accept incoming requests - i.e., to respond to queries from others about your addr/port. Let's say that place is behind a NAT. Then *it* needs to similarly publish its address and port. And so on... i.e., besides begging the question of how you can find out your public address/port without cooperation from your NAT or a server on a public port, even if you had cooperation from your NAT you still need to deposit this info somewhere public. NATs *rely* on the fact that some places aren't NAT'd. I.e., they are Nietzschian - NATs are for the 'special'; the commoners need to be on the public NAT, exposed in infrastructure and open to incoming services. > +------ request ------+ > V | > [You] -- publish --> [Service] -- response --> [Me] > >> With NATs, I need to know YOU are calling be somehow, so that I can do >> something to trigger the NAT upstream from me > > Also true. Simply change the service above to notify you when someone > wants to contact you. Er - how does that service know that? The service needs to be on the public net to accept the call that indicates someone called it to call you. > +------ request ------+ > V | > [You] -- publish --> [Service] -- response --> [Me] > A | > +----- notify ---------+ > >> The only way to do that is via a server on the public Internet (short of >> a telephone, which can cheat in any coordination system). > > The service doesn't have to be "on" the public internet, but rather > accessible from the public Internet. In particular, the service can > run behind a NAT that the service provider controls. The service > provider configures the NAT to forward inbound queries to the correct > private address. The server needs to be "on the public Internet". It needs to lack the intended protections of NATs. It needs to have a public address open to incoming connections, and that information needs to be advertised. Whether it's tunneled behind a NAT that isn't hiding it is irrelevant. >> I.e., a NAT'd Internet is an incomplete architecture; it cannot usefully >> exist without non-NAT'd servers. > > Certainly, this service above would have to be part of the architecture > to complete it. Just as DNS is now a part of the IP architecture. The DNS is part of the IP architecture. The service above must be OUTSIDE the NAT architecture. Joe From touch at ISI.EDU Wed Feb 22 07:48:24 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 22 Feb 2006 07:48:24 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <20060222085720.6477C1A0214@smtp-1.hotpop.com> References: <20060222085720.6477C1A0214@smtp-1.hotpop.com> Message-ID: <43FC87C8.40706@isi.edu> alok wrote: >> But would any OS stack out there support this sort of a transaction, based >> completely on "$who-->send data" instead of the recursive "$who-->$where > and >> then send data"? > > The OS isn't what needs to support it; the name needs to go in the IP > packet. Which means routing on DNS names. See TRIAD. > > With respect to NATs, you're just asking to have names rewritten; this > doesn't solve anything. > > => > yes like TRIAD, except that it works differently when I have multiple NATs. > It tends to "go up" and come down the same way. > > Take for example: (assuming all nodes are triad nodes) > > PC1--node1----node2--Node3--PC2 > | | | | > +----Node4---Node5--node6---+ > > If PC1 connects to PC2 via NAT1-NaT2-Nat3, PC2 is constrained to reply via > NAT3-Nat2-Nat1. You didn't say how PC1 finds out that it should go n1-n2-n3, vs. n1-n4-n5, or even back to p1. It needs to route. Which means it needs a publicly routable ID for p2, which means that n2 needs to know where p2 is. But n2 never sees p2's ID; it only sees n3's. > A bit different from the way the internet behaves today, is it not? And not in a good way, IMO ;-) I like a net that works (above) and that scales. Even if it worked, it would rely on a kind of source-routed state that was deposited in the NATs - on a per-endpoint pair basis. > I may have xMb uplink via node1 but a 10xMb downlink via node4. > > It may not matter if the NAT is close to the edge PC but it does matter as > he NAT moves further up in the provider network, or at least it did when I > used to try installing web caches. From perfgeek at mac.com Wed Feb 22 08:24:50 2006 From: perfgeek at mac.com (rick jones) Date: Wed, 22 Feb 2006 08:24:50 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <1140597129.31192.14.camel@localhost.localdomain> References: <20060222054913.218AA1A067D@smtp-1.hotpop.com> <43FBFF99.8090105@isi.edu> <1140597129.31192.14.camel@localhost.localdomain> Message-ID: <92aefb72e0133084ae608f1e0cee0ca1@mac.com> On Feb 22, 2006, at 12:32 AM, Saikat Guha wrote: > On Tue, 2006-02-21 at 22:07 -0800, Joe Touch wrote: >> IDs need to be in the packets. However, that >> just invites NA(P)T designers to evolve to NAPNT (add name >> translation). > > NATs (not counting firewalls) are used to extend the IPv4 address > space. > The address space for "names" is infinite. Is there a motivation behind > designing or deploying name-translation devices? names (in the DNS or something like it I presume?) may be essentially infinite, but are they "free?" IIRC even with IPv4 ISP's were/are offering multiple IPs to customers - for a price - ostensibly a price perceived to be higher than that of procuring and running a NAT. I also thought that NAT's were used to provide some (small) measure of anonymity. rick jones Wisdom teeth are impacted, people are affected by the effects of events From saikat at cs.cornell.edu Wed Feb 22 09:05:20 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Wed, 22 Feb 2006 12:05:20 -0500 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FC85A2.3050303@isi.edu> References: <010201c636ac$50197bc0$c4f0200a@amer.cisco.com> <43FAB4EA.5020009@isi.edu> <1140598324.31192.34.camel@localhost.localdomain> <43FC85A2.3050303@isi.edu> Message-ID: <1140627920.22163.10.camel@localhost.localdomain> On Wed, 2006-02-22 at 07:39 -0800, Joe Touch wrote: > Saikat Guha wrote: > > there is a service that allows you > > somehow publish your IP address and port > > Let's say that place is behind a NAT. Then *it* needs to similarly > publish its address and port. or, this address and port may be hard-coded into clients as is the case with the DNS root servers. Alternatively, if DNS is around, the address and port can be published there. In any event, yes, this service needs to be publicly accessible. > The DNS is part of the IP architecture. The service above must be > OUTSIDE the NAT architecture. Just as DNS is useless unless clients know the _IP_ of the root, a NAT'ed Internet is useless unless the clients can publicly reach the rendezvous. You cannot reach the DNS root using DNS, and you cannot reach the rendezvous that requires a rendezvous. I don't understand your distinction for considering one inside, and the other outside the respective architectures. -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060222/44ca1295/attachment.bin From touch at ISI.EDU Wed Feb 22 09:13:50 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 22 Feb 2006 09:13:50 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <1140627920.22163.10.camel@localhost.localdomain> References: <010201c636ac$50197bc0$c4f0200a@amer.cisco.com> <43FAB4EA.5020009@isi.edu> <1140598324.31192.34.camel@localhost.localdomain> <43FC85A2.3050303@isi.edu> <1140627920.22163.10.camel@localhost.localdomain> Message-ID: <43FC9BCE.5030805@isi.edu> Saikat Guha wrote: > On Wed, 2006-02-22 at 07:39 -0800, Joe Touch wrote: >> Saikat Guha wrote: >>> there is a service that allows you >>> somehow publish your IP address and port >> Let's say that place is behind a NAT. Then *it* needs to similarly >> publish its address and port. > > or, this address and port may be hard-coded into clients as is the case > with the DNS root servers. Alternatively, if DNS is around, the address > and port can be published there. In any event, yes, this service needs > to be publicly accessible. > >> The DNS is part of the IP architecture. The service above must be >> OUTSIDE the NAT architecture. > > Just as DNS is useless unless clients know the _IP_ of the root, a > NAT'ed Internet is useless unless the clients can publicly reach the > rendezvous. You cannot reach the DNS root using DNS, and you cannot > reach the rendezvous that requires a rendezvous. > > I don't understand your distinction for considering one inside, and the > other outside the respective architectures. Fair enough. The DNS is optional in the Internet. In the Internet, if I am behind a NAT and want to reach you, I need to know your public IP address and the port that you will listen on. You do NOT need to know _I_ will contact you, you do not need to know my IP address, and you do not need to know my source port; you can accept 'any incoming'. NATs don't work that way - my knowing your contact info isn't enough; you need to know I'm coming. Destination address and port are insufficient to demultiplex incoming calls; you NEED source address and port, and you NEED a DNS-like structure to accomplish that. I'll grant that the DNS sits outside the Internet network architecture the same way that NAT-host registries do. But NAT'd systems are a network structure that won't forward packets unless such a service exists; the Internet doesn't require that. Joe From dpreed at reed.com Wed Feb 22 09:20:03 2006 From: dpreed at reed.com (David P. Reed) Date: Wed, 22 Feb 2006 12:20:03 -0500 Subject: [e2e] 0% NAT - checkmating the disconnectors In-Reply-To: <43FC87C8.40706@isi.edu> References: <20060222085720.6477C1A0214@smtp-1.hotpop.com> <43FC87C8.40706@isi.edu> Message-ID: <43FC9D43.7010800@reed.com> So, in the spirit of potentially opening up a can of worms (pardon the pun!) for those of us who believe an open, well-lit Internet is better than a dark and dank collection of twisty passages and side streets of the sort being constructed by the security mavens and their opponents ... Does anyone have any good thoughts on how to collectively create the next generation *Inter* Net - one that actually provides the interoperability that all of us old codgers dreamed was possible when Licklider, Taylor, Englebart, etc. first imagined it and Vint Cerf and Bob Kahn made it happen? Of course we need to pay attention to real security and create a space that is inherently safe both from bad guys and guys like Verizon and SBC and oppressive governments who want to decide what connections should be allowed, while denying all others. It seems that the action will be in creating a pervasive, and easy-to-adopt flexible, secure and resilient overlay. One where the bad boy "gunslingers" who offer "protection" on behalf of our employers and governments can't scare the kiddies off the streets, and allow us to take back the Internet. We know that NATs don't protect us very well, and we know that firewalls don't either. Yet they sure get in the way and create points of power for those who would keep us disconnected. We also know that Microsoft, Linux, and Apple (among others) are under tremendous pressure to "save us", so they are pouring more and more "disconnectivity" into their platforms in the form of packet inspection and mandatory, non-discretionary controls on what can be done. None of this garbage is being thought through critically in terms of its global impact - instead it's being piled in heaps and gobs all throughout the network. Who speaks for connectivity? Who speaks for openness? Fewer and fewer, it seems. From saikat at cs.cornell.edu Wed Feb 22 09:28:55 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Wed, 22 Feb 2006 12:28:55 -0500 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <92aefb72e0133084ae608f1e0cee0ca1@mac.com> References: <20060222054913.218AA1A067D@smtp-1.hotpop.com> <43FBFF99.8090105@isi.edu> <1140597129.31192.14.camel@localhost.localdomain> <92aefb72e0133084ae608f1e0cee0ca1@mac.com> Message-ID: <1140629335.22163.28.camel@localhost.localdomain> On Wed, 2006-02-22 at 08:24 -0800, rick jones wrote: > On Feb 22, 2006, at 12:32 AM, Saikat Guha wrote: > > NATs (not counting firewalls) are used to extend the IPv4 address > > space. > > The address space for "names" is infinite. Is there a motivation behind > > designing or deploying name-translation devices? > > names (in the DNS or something like it I presume?) may be essentially > infinite, but are they "free?" IIRC even with IPv4 ISP's were/are > offering multiple IPs to customers - for a price I imagine that price stems from the scarcity of IPs in the ISP's address block. ISP's routinely offer customers multiple free email addresses. > I also thought that NAT's were used to provide some (small) measure of > anonymity. Names need not betray organizational topology, nor prevent anonymity. NATs are a hack to circumvent IP routing without changing endhosts. A name-based routing would require changing endhosts anyway. It would also allow implementing these "services" that NATs provides now, at the endhosts themselves. Clever name-based routing protocols (i3 for example) can reach the destination without requiring NATs in the middle for anonymity and topology hiding. -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060222/7bc1ac50/attachment.bin From dga+ at cs.cmu.edu Wed Feb 22 09:46:04 2006 From: dga+ at cs.cmu.edu (David Andersen) Date: Wed, 22 Feb 2006 12:46:04 -0500 Subject: [e2e] 0% NAT - checkmating the disconnectors In-Reply-To: <43FC9D43.7010800@reed.com> References: <20060222085720.6477C1A0214@smtp-1.hotpop.com> <43FC87C8.40706@isi.edu> <43FC9D43.7010800@reed.com> Message-ID: <34C24C40-4712-4DEE-AEDD-7782C26A6936@cs.cmu.edu> On Feb 22, 2006, at 12:20 PM, David P. Reed wrote: > > Does anyone have any good thoughts on how to collectively create > the next generation *Inter* Net - one that actually provides the > interoperability that all of us old codgers dreamed was possible > when Licklider, Taylor, Englebart, etc. first imagined it and Vint > Cerf and Bob Kahn made it happen? Yes. But we're all writing FIND proposals about the ideas. I'll follow up on this in a week and a half, if I remember or am prodded appropriately. > It seems that the action will be in creating a pervasive, and easy- > to-adopt flexible, secure and resilient overlay. One where the > bad boy "gunslingers" who offer "protection" on behalf of our > employers and governments can't scare the kiddies off the streets, > and allow us to take back the Internet. I hear overlays are overrated. > > None of this garbage is being thought through critically in terms > of its global impact - instead it's being piled in heaps and gobs > all throughout the network. > > Who speaks for connectivity? Who speaks for openness? Fewer and > fewer, it seems. Try: http://www.cs.cmu.edu/~dga/ngsi.pdf It'ss a one-page (ish) position paper I scribbled up for the NSF next generation secure internet workshop that was held at CMU some time last year. It's drafty, probably poorly thought out, and wasn't really intended for wide dissemination -- but I believe pretty strongly in what it says. Caveat: It has no answers, only questions, and a couple of philosophical design requirements about not breaking the beautiful things about today's Internet. I'll start tossing answers at you next week. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060222/d7ac289a/PGP-0001.bin From touch at ISI.EDU Wed Feb 22 09:52:35 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 22 Feb 2006 09:52:35 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <1140629335.22163.28.camel@localhost.localdomain> References: <20060222054913.218AA1A067D@smtp-1.hotpop.com> <43FBFF99.8090105@isi.edu> <1140597129.31192.14.camel@localhost.localdomain> <92aefb72e0133084ae608f1e0cee0ca1@mac.com> <1140629335.22163.28.camel@localhost.localdomain> Message-ID: <43FCA4E3.9080401@isi.edu> Saikat Guha wrote: > On Wed, 2006-02-22 at 08:24 -0800, rick jones wrote: > >>On Feb 22, 2006, at 12:32 AM, Saikat Guha wrote: >> >>>NATs (not counting firewalls) are used to extend the IPv4 address >>>space. >>>The address space for "names" is infinite. Is there a motivation behind >>>designing or deploying name-translation devices? >> >>names (in the DNS or something like it I presume?) may be essentially >>infinite, but are they "free?" IIRC even with IPv4 ISP's were/are >>offering multiple IPs to customers - for a price > > > I imagine that price stems from the scarcity of IPs in the ISP's address > block. ISP's routinely offer customers multiple free email addresses. Price != cost. In this case, price stems from the ISP's desire to differentiate (artificially) the difference between commercial customers and individual consumers. In some cases, getting a real IP address requires converting an account to commercial. >>I also thought that NAT's were used to provide some (small) measure of >>anonymity. > > Names need not betray organizational topology, nor prevent anonymity. IP addresses don't betray topology; you can have source routes throughout an organization. As to anonymity, that's exactly what they prevent unless the NAT rewrites the name. > NATs are a hack to circumvent IP routing without changing endhosts. A > name-based routing would require changing endhosts anyway. It would also > allow implementing these "services" that NATs provides now, at the > endhosts themselves. Clever name-based routing protocols (i3 for > example) can reach the destination without requiring NATs in the middle > for anonymity and topology hiding. Yes, there are other ways to hide topology and protect hosts that don't involve NATs; unfortunately, NATs are the dominant solution in play. Joe From touch at ISI.EDU Wed Feb 22 10:34:27 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 22 Feb 2006 10:34:27 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: References: <010201c636ac$50197bc0$c4f0200a@amer.cisco.com> <43FAB4EA.5020009@isi.edu> <1140598324.31192.34.camel@localhost.localdomain> <43FC85A2.3050303@isi.edu> <1140627920.22163.10.camel@localhost.localdomain> <43FC9BCE.5030805@isi.edu> Message-ID: <43FCAEB3.2080503@isi.edu> Andrew Warfield wrote: >>I'll grant that the DNS sits outside the Internet network architecture >>the same way that NAT-host registries do. But NAT'd systems are a >>network structure that won't forward packets unless such a service >>exists; the Internet doesn't require that. > > By "the Internet" here, you mean "the part of the Internet that > doesn't sit behind NATs", right? The "Internet" means, IMO, the part of the network that follows Internet rules, which mean: - globally-routable addresses - hop-by-hop forwarding using local rules The part behind NATs are serviced by a proxy (the NAT box) with data communications capabilities, but it's definitely NOT the Internet back there. Joe From saikat at cs.cornell.edu Wed Feb 22 11:18:23 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Wed, 22 Feb 2006 14:18:23 -0500 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FC9BCE.5030805@isi.edu> References: <010201c636ac$50197bc0$c4f0200a@amer.cisco.com> <43FAB4EA.5020009@isi.edu> <1140598324.31192.34.camel@localhost.localdomain> <43FC85A2.3050303@isi.edu> <1140627920.22163.10.camel@localhost.localdomain> <43FC9BCE.5030805@isi.edu> Message-ID: <1140635903.13834.19.camel@localhost.localdomain> On Wed, 2006-02-22 at 09:13 -0800, Joe Touch wrote: > Fair enough. The DNS is optional in the Internet. > > In the Internet, if I am behind a NAT and want to reach you, I need to > know your public IP address and the port that you will listen on. > > You do NOT need to know _I_ will contact you, you do not need to know my > IP address, and you do not need to know my source port; you can accept > 'any incoming'. You implicitly make the assumption that I am willing to accept your (and indiscriminately everyone else's) packets. Anyone behind a firewall, either by choice or not, would likely agree that this classic assumption is no longer substantiated in general. If the packet is from a known worm-infected address, I don't want it. My ISP doesn't want me to receive it lest I wreak havoc on their network. Most likely, your ISP won't want you to send it in the first place. > NATs don't work that way - my knowing your contact info isn't enough; > you need to know I'm coming. Destination address and port are > insufficient to demultiplex incoming calls; you NEED source address and > port, and you NEED a DNS-like structure to accomplish that. The "NEED" for source address and port based demultiplex is due more to security concerns than NATs. Before I let you in, I want to know who you are, what you are trying to send me and why, and I might as well negotiate how and at what address we can exchange packets. The mechanistic requirements of the NAT'ed Internet conveniently coincide with the present security requirements. One may very well leverage the other imho. -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060222/953941a4/attachment.bin From touch at ISI.EDU Wed Feb 22 11:35:10 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 22 Feb 2006 11:35:10 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <1140635903.13834.19.camel@localhost.localdomain> References: <010201c636ac$50197bc0$c4f0200a@amer.cisco.com> <43FAB4EA.5020009@isi.edu> <1140598324.31192.34.camel@localhost.localdomain> <43FC85A2.3050303@isi.edu> <1140627920.22163.10.camel@localhost.localdomain> <43FC9BCE.5030805@isi.edu> <1140635903.13834.19.camel@localhost.localdomain> Message-ID: <43FCBCEE.6070605@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Saikat Guha wrote: > On Wed, 2006-02-22 at 09:13 -0800, Joe Touch wrote: > >>Fair enough. The DNS is optional in the Internet. >> >>In the Internet, if I am behind a NAT and want to reach you, I need to >>know your public IP address and the port that you will listen on. >> >>You do NOT need to know _I_ will contact you, you do not need to know my >>IP address, and you do not need to know my source port; you can accept >>'any incoming'. > > > You implicitly make the assumption that I am willing to accept your (and > indiscriminately everyone else's) packets. Anyone behind a firewall, > either by choice or not, would likely agree that this classic assumption > is no longer substantiated in general. > > If the packet is from a known worm-infected address, I don't want it. My > ISP doesn't want me to receive it lest I wreak havoc on their network. > Most likely, your ISP won't want you to send it in the first place. That's what firewalls are for. NATs don't block infected sources; they block only sources you didn't expect packets from. >>NATs don't work that way - my knowing your contact info isn't enough; >>you need to know I'm coming. Destination address and port are >>insufficient to demultiplex incoming calls; you NEED source address and >>port, and you NEED a DNS-like structure to accomplish that. > > The "NEED" for source address and port based demultiplex is due more to > security concerns than NATs. Before I let you in, I want to know who you > are, what you are trying to send me and why, and I might as well > negotiate how and at what address we can exchange packets. You do that inside the packet exchange - e.g., using SSL or IPsec E2E. Just blocking on the source IP address and port that you didn't expect isn't security - it's service blocking. > The mechanistic requirements of the NAT'ed Internet conveniently > coincide with the present security requirements. One may very well > leverage the other imho. NATs coincide with the model that consumers are clients and commercial entities are servers. When that's not the case (VoIP, software maintenance via web service portals, etc.), NATs do not coincide. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/LzuE5f5cImnZrsRAhUMAKCVRLEzv5qWaLZQ1NgALOeKIclHpACgju3J LGOIEZcoI2eYpTKtpaa/CuI= =SMgc -----END PGP SIGNATURE----- From dwing at cisco.com Wed Feb 22 11:45:40 2006 From: dwing at cisco.com (Dan Wing) Date: Wed, 22 Feb 2006 11:45:40 -0800 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FCBCEE.6070605@isi.edu> Message-ID: <082a01c637e8$8fe3d010$8b82200a@amer.cisco.com> > That's what firewalls are for. NATs don't block infected sources; they > block only sources you didn't expect packets from. Some NATs have that characteristic, yes. Some don't. draft-jennings-midcom-stun-results-02.txt (now expired) contains test results of about 20 NATs. Several of those are "full cone", which means they do not restrict incoming UDP packets to certain hosts. ... > You do that inside the packet exchange - e.g., using SSL or IPsec E2E. > Just blocking on the source IP address and port that you didn't expect > isn't security - it's service blocking. Agreed. And blocking it at the subscriber side of a bandwidth- constrained access link is arguably the wrong place to have such blocking, anyway. -d > > The mechanistic requirements of the NAT'ed Internet conveniently > > coincide with the present security requirements. One may very well > > leverage the other imho. > > NATs coincide with the model that consumers are clients and commercial > entities are servers. When that's not the case (VoIP, software > maintenance via web service portals, etc.), NATs do not coincide. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFD/LzuE5f5cImnZrsRAhUMAKCVRLEzv5qWaLZQ1NgALOeKIclHpACgju3J > LGOIEZcoI2eYpTKtpaa/CuI= > =SMgc > -----END PGP SIGNATURE----- From saikat at cs.cornell.edu Wed Feb 22 13:04:50 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Wed, 22 Feb 2006 16:04:50 -0500 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FCCBEA.5010703@reed.com> References: <010201c636ac$50197bc0$c4f0200a@amer.cisco.com> <43FAB4EA.5020009@isi.edu> <1140598324.31192.34.camel@localhost.localdomain> <43FC85A2.3050303@isi.edu> <1140627920.22163.10.camel@localhost.localdomain> <43FC9BCE.5030805@isi.edu> <1140635903.13834.19.camel@localhost.localdomain> <43FCCBEA.5010703@reed.com> Message-ID: <1140642290.13834.42.camel@localhost.localdomain> On Wed, 2006-02-22 at 15:39 -0500, David P. Reed wrote: > >The mechanistic requirements of the NAT'ed Internet conveniently > >coincide with the present security requirements. > > > > Note that > the NAT inventors NEVER claimed security as the goal My apologies, I wasn't clear -- I don't mean to imply NATs have anything to do with security. I mean that the *mechanisms* necessitated by NATs are also useful from a security standpoint. In particular, NATs require end-hosts to *negotiate* addresses. This negotiation is end-to-end, and bi-directional. Security requires end-hosts to negotiate identities, encryption, etc. in a similar fashion. If the Internet were to provide this end-to-end bi-directional "negotiation" as a primitive, it could be used for both address translation as well as for security. NATs force the rendezvous to provide such a negotiation primitive. Security can benefit from this primitive (not from the NATs per se). cheers, -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060222/ac2717db/attachment.bin From avg at kotovnik.com Wed Feb 22 13:52:43 2006 From: avg at kotovnik.com (Vadim Antonov) Date: Wed, 22 Feb 2006 13:52:43 -0800 (PST) Subject: [e2e] 0% NAT - checkmating the disconnectors In-Reply-To: <43FC9D43.7010800@reed.com> Message-ID: On Wed, 22 Feb 2006, David P. Reed wrote: > Does anyone have any good thoughts on how to collectively create the > next generation *Inter* Net - one that actually provides the > interoperability that all of us old codgers dreamed was possible when > Licklider, Taylor, Englebart, etc. first imagined it and Vint Cerf and > Bob Kahn made it happen? I do, but it involves some rather drastic changes in the way software is designed. And, no, I didn't figure out how to make an economic case or a viable business plan out of that. The problem, by far, is not in the Internet itself, but in the fact that the end-systems are, frankly, a pile of badly designed and hastily slapped-together manure. The proprietary software development, dependent on the intellectual "property" (which is not property, but, rather, government granted monopoly privilege) protection, is in many aspects driven by the need to preserve the loot brought to the privilege holder by the protection. It is totally unrealistic to expect any such development to be concerned with interoperability with competitors and such, or with competing on quality - after all, once the privelege rights are obtained by locking-in the customers, there's no further reason to improve. The "bazaar" model is somewhat better but, being mostly ego-driven and dependent on final-product contributions from obviously inexperienced professionals-in-training (show me a real professional working in the industry on the product-delivery track who actually has time to do free software) and amateurs, seems to be very good at producing mountains of garbage conisting of countless variations on similar simple themes. We have abandoned any pretense of software production being scientific, and reverted to artisan attitudes, and thus made it impossible to accumulate experience and knowledge in a way immediately accessible and useful to other practitioners (we even sunk to the point of being incapable of replicating older achievements -- watch the FAA systems upgrade saga). It is painful to see generation after generation of bright young software jockeys doing exactly the same old mistakes. Of course, the evolution will take care of improving things, but it is bound to be very slow. There weren't any truly groundbreaking ideas in the software industry for a decade, at least. What we have instead are 30-year-old technologies being embellished and bloated by featuritis. By and large, the state-of-the-art approached the state-of-a-garbage-dump - which, undoubtly, contains a lot of useful and valuable pieces, but which is so full of junk that it makes is easier to make a new piece than to find an old one fitting the purpose - thus adding to the ever-growing mountain of irrelevant, partially working, and incomplete (and, yes, insecure). And taking a potentially interesting idea and making it into a useful product involves years of hard mind-numbing labour; every time repeating the steps of building from the ground up. I wish I didn't have to write a doubly-linked list (just to give an example) hundred times over the last twenty years just to work around intellectual "property" protections, language ideosyncracies, library compatibility issues, different languages and simply because it is faster to do so than to use baroque templates. Thus, many good ideas are simply abandoned: very few people would be prepared to put in the years of their life (and have the ability to survive these years with no income) into a pursuit of an idea. So... how about a culture shift? An ascetic religion, perhaps, which dictates that the high virtue is quality improvement, simplification and generalization rather than hacking away? Something which makes improving productivity of software design a worthier goal than delivery of the end-product? A culture which measures worth of a professional not by the amount of new stuff he built but by the amount of trivial coding and trivia learning he eliminated? Valuing coherent general explanations and designs over data and code? Discipline and precision over creative energy and unfettered fantasy? Science, not art. I do have some ideas on specific steps in that direction (so, apparently, do many other people... and some corporations even flirted with trying to get there, although these projects were quickly perverted and destroyed by the corporate politics and short-termism). I'm also keenly aware that any efforts in this direction will not be able to pay for themselves for many many years (if ever), are uncertain, and can be susustained only by faith and belief into the transcendent value of beauty and truth themselves. Anyone wishes to donate to the establishment of the new software religion? --vadim From Jon.Crowcroft at cl.cam.ac.uk Wed Feb 22 15:04:51 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 22 Feb 2006 23:04:51 +0000 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: Message from Joe Touch of "Wed, 22 Feb 2006 10:34:27 PST." <43FCAEB3.2080503@isi.edu> Message-ID: fine - continuing a) to be irrelevent to an operational definition of the internet b) to be fail to be a useful way to figure out how to evovle but terribly useful no doubt for homeland security and politically (i.e. e2e) correct. commercially and intellectually, a dead end. a cartoon in iran In missive <43FCAEB3.2080503 at isi.edu>, Joe Touch typed: >> >> >>Andrew Warfield wrote: >>>>I'll grant that the DNS sits outside the Internet network architecture >>>>the same way that NAT-host registries do. But NAT'd systems are a >>>>network structure that won't forward packets unless such a service >>>>exists; the Internet doesn't require that. >>> >>> By "the Internet" here, you mean "the part of the Internet that >>> doesn't sit behind NATs", right? >> >>The "Internet" means, IMO, the part of the network that follows Internet >>rules, which mean: >> >>- globally-routable addresses >>- hop-by-hop forwarding using local rules >> >>The part behind NATs are serviced by a proxy (the NAT box) with data >>communications capabilities, but it's definitely NOT the Internet back >>there. >> >>Joe cheers jon From Jon.Crowcroft at cl.cam.ac.uk Wed Feb 22 15:08:53 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 22 Feb 2006 23:08:53 +0000 Subject: [e2e] 0% NAT - checkmating the disconnectors In-Reply-To: Message from David Andersen of "Wed, 22 Feb 2006 12:46:04 EST." <34C24C40-4712-4DEE-AEDD-7782C26A6936@cs.cmu.edu> Message-ID: In missive <34C24C40-4712-4DEE-AEDD-7782C26A6936 at cs.cmu.edu>, David Andersen typed: >>But we're all writing FIND proposals about the ideas. I'll follow up >>on this in a week and a half, if I remember or am prodded appropriately. no we arent. we are not eligable for funding in the fine Global ENI vision that FIND is building fact is - the interesting biits are wireless. story is the US centric piece is pointless if the infrastructure is about go faster stripes. but anyhow, i am not a stakeholder so i am safely ignored. gosh, what a mess j. From imcdnzl at gmail.com Tue Feb 21 11:41:35 2006 From: imcdnzl at gmail.com (Ian McDonald) Date: Wed, 22 Feb 2006 08:41:35 +1300 Subject: [e2e] TCP Delayed Ack In-Reply-To: <43F58D70.3070900@iit.cnr.it> References: <43F58D70.3070900@iit.cnr.it> Message-ID: > > Do you know about a way to disable the TCP Delayed Ack on Linux? > (just for test purpose) > If all else fails edit the source.... There are benefits to open source :-) Ian -- Ian McDonald http://wand.net.nz/~iam4 WAND Network Research Group Department of Computer Science University of Waikato New Zealand From alokdube at hotPOP.com Wed Feb 22 23:21:05 2006 From: alokdube at hotPOP.com (alok) Date: Thu, 23 Feb 2006 12:51:05 +0530 Subject: [e2e] 100% NAT - a DoS proof internet In-Reply-To: <43FC87C8.40706@isi.edu> Message-ID: <20060223072102.3E97E1A01EB@smtp-1.hotpop.com> alok wrote: >> But would any OS stack out there support this sort of a transaction, based >> completely on "$who-->send data" instead of the recursive "$who-->$where > and >> then send data"? > > The OS isn't what needs to support it; the name needs to go in the IP > packet. Which means routing on DNS names. See TRIAD. > > With respect to NATs, you're just asking to have names rewritten; this > doesn't solve anything. > > => > yes like TRIAD, except that it works differently when I have multiple NATs. > It tends to "go up" and come down the same way. > > Take for example: (assuming all nodes are triad nodes) > > PC1--node1----node2--Node3--PC2 > | | | | > +----Node4---Node5--node6---+ > > If PC1 connects to PC2 via NAT1-NaT2-Nat3, PC2 is constrained to reply via > NAT3-Nat2-Nat1. You didn't say how PC1 finds out that it should go n1-n2-n3, vs. n1-n4-n5, or even back to p1. It needs to route. Which means it needs a publicly routable ID for p2, which means that n2 needs to know where p2 is. But n2 never sees p2's ID; it only sees n3's. --> The label could be "local" between the 2 nodes as zaphod pointed out :-) > A bit different from the way the internet behaves today, is it not? And not in a good way, IMO ;-) I like a net that works (above) and that scales. Even if it worked, it would rely on a kind of source-routed state that was deposited in the NATs - on a per-endpoint pair basis. --> :) From sampad_m at rediffmail.com Thu Feb 23 02:45:56 2006 From: sampad_m at rediffmail.com (sampad mishra) Date: 23 Feb 2006 10:45:56 -0000 Subject: [e2e] applcation layer!!!! Message-ID: <20060223104556.5723.qmail@webmail7.rediffmail.com> Hi all, As the DOS attack issue is getting heated up in the group. I would like to divert your attention a bit. As we know the current trends in the Internet technology points to an increasingly heterogeneous network consisting of links of vastly different characteristics. Satellite networks, WLANS, mobiles will be ubiquitous and an integral part of the future Internet. As we have seen all the layers of OSI model evolving , can anyone throw some light how application layer is evolving inorder to take into account the heterogenity of the network. Is any changes in the application framework been proposed which can give a better perfomance taking into account the heterogenity of the network. I mean to say has anyone looked from the application point of view, or is it better to keep the application unaware of the medium. I'm sorry if the above question is irrelevant or may be stupid but atleast I would expect some comments.... Regards, Sampad Mishra, IISc. Bangalore. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060223/3715ad51/attachment.html From sampad_m at rediffmail.com Thu Feb 23 02:46:14 2006 From: sampad_m at rediffmail.com (sampad mishra) Date: 23 Feb 2006 10:46:14 -0000 Subject: [e2e] applcation layer!!!! Message-ID: <20060223104614.6725.qmail@webmail53.rediffmail.com> Hi all, As the DOS attack issue is getting heated up in the group. I would like to divert your attention a bit. As we know the current trends in the Internet technology points to an increasingly heterogeneous network consisting of links of vastly different characteristics. Satellite networks, WLANS, mobiles will be ubiquitous and an integral part of the future Internet. As we have seen all the layers of OSI model evolving , can anyone throw some light how application layer is evolving inorder to take into account the heterogenity of the network. Is any changes in the application framework been proposed which can give a better perfomance taking into account the heterogenity of the network. I mean to say has anyone looked from the application point of view, or is it better to keep the application unaware of the medium. I'm sorry if the above question is irrelevant or may be stupid but atleast I would expect some comments.... Regards, Sampad Mishra, IISc. Bangalore. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060223/a797d8d2/attachment.html From lynne at telemuse.net Thu Feb 23 15:50:48 2006 From: lynne at telemuse.net (Lynne Jolitz) Date: Thu, 23 Feb 2006 15:50:48 -0800 Subject: [e2e] 0% NAT - checkmating the disconnectors In-Reply-To: Message-ID: <001401c638d3$f871cba0$6e8944c6@telemuse.net> Vadim, You are so correct here. The social issues of the Internet and developers make them terribly insecure about refining a concept or package of software with the technique of minimalism. And so they tend to jump to reductionism as a means to avoiding ridicule and social pressure. And as the Internet becomes more and more the metaphor through which we all appear, this fear of ridicule will result in less and less challenging work and more and more variations on the same theme - kind of like the way Hollywood mimics a success so that everything becomes a "reality TV" show or a "Desparate Housewives" sequel for a season. You might find this article on CNET of interest entitled "Misplaced Software Priorities": http://news.com.com/Misplaced+software+priorities/2010-1007_3-5745970.html It speaks to your concerns. Lynne Jolitz PS - NAT is an economic issue. As long as a v4 static address has a market value of $20-$40 per month retail on top of basic connectivity for small business / home, nobody will want to pay for more than one (if even they get one), much less one per server. The exception is Japan with IPv6 cellphones with throwaway IP addresses. In this case, there was no economic incentive for NAT. It all comes down to money out of pocket. The security and other issues can be dealt with in many different ways. -lgj ---- We use SpamQuiz. If your ISP didn't make the grade try http://lynne.telemuse.net > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org]On Behalf Of Vadim Antonov > Sent: Wednesday, February 22, 2006 1:53 PM > To: David P. Reed > Cc: end2end-interest at postel.org > Subject: Re: [e2e] 0% NAT - checkmating the disconnectors > > > On Wed, 22 Feb 2006, David P. Reed wrote: > > > Does anyone have any good thoughts on how to collectively create the > > next generation *Inter* Net - one that actually provides the > > interoperability that all of us old codgers dreamed was possible when > > Licklider, Taylor, Englebart, etc. first imagined it and Vint Cerf and > > Bob Kahn made it happen? > > I do, but it involves some rather drastic changes in the way software is > designed. And, no, I didn't figure out how to make an economic case or a > viable business plan out of that. > > The problem, by far, is not in the Internet itself, but in the fact that > the end-systems are, frankly, a pile of badly designed and hastily > slapped-together manure. > > The proprietary software development, dependent on the intellectual > "property" (which is not property, but, rather, government granted > monopoly privilege) protection, is in many aspects driven by the need to > preserve the loot brought to the privilege holder by the protection. It > is totally unrealistic to expect any such development to be concerned with > interoperability with competitors and such, or with competing on > quality - > after all, once the privelege rights are obtained by locking-in the > customers, there's no further reason to improve. > > The "bazaar" model is somewhat better but, being mostly ego-driven and > dependent on final-product contributions from obviously inexperienced > professionals-in-training (show me a real professional working in the > industry on the product-delivery track who actually has time to do free > software) and amateurs, seems to be very good at producing mountains of > garbage conisting of countless variations on similar simple themes. > > We have abandoned any pretense of software production being scientific, > and reverted to artisan attitudes, and thus made it impossible to > accumulate experience and knowledge in a way immediately accessible and > useful to other practitioners (we even sunk to the point of being > incapable of replicating older achievements -- watch the FAA systems > upgrade saga). It is painful to see generation after generation of bright > young software jockeys doing exactly the same old mistakes. Of course, > the evolution will take care of improving things, but it is bound to be > very slow. > > There weren't any truly groundbreaking ideas in the software industry for > a decade, at least. What we have instead are 30-year-old technologies > being embellished and bloated by featuritis. By and large, the > state-of-the-art approached the state-of-a-garbage-dump - which, > undoubtly, contains a lot of useful and valuable pieces, but which is so > full of junk that it makes is easier to make a new piece than to find an > old one fitting the purpose - thus adding to the ever-growing mountain of > irrelevant, partially working, and incomplete (and, yes, insecure). > > And taking a potentially interesting idea and making it into a useful > product involves years of hard mind-numbing labour; every time repeating > the steps of building from the ground up. I wish I didn't have to write a > doubly-linked list (just to give an example) hundred times over the last > twenty years just to work around intellectual "property" protections, > language ideosyncracies, library compatibility issues, different languages > and simply because it is faster to do so than to use baroque templates. > Thus, many good ideas are simply abandoned: very few people would be > prepared to put in the years of their life (and have the ability to > survive these years with no income) into a pursuit of an idea. > > So... how about a culture shift? An ascetic religion, perhaps, which > dictates that the high virtue is quality improvement, simplification and > generalization rather than hacking away? Something which makes improving > productivity of software design a worthier goal than delivery of the > end-product? A culture which measures worth of a professional not by the > amount of new stuff he built but by the amount of trivial coding and > trivia learning he eliminated? Valuing coherent general explanations and > designs over data and code? Discipline and precision over creative energy > and unfettered fantasy? Science, not art. > > I do have some ideas on specific steps in that direction (so, apparently, > do many other people... and some corporations even flirted with trying to > get there, although these projects were quickly perverted and destroyed by > the corporate politics and short-termism). I'm also keenly aware that any > efforts in this direction will not be able to pay for themselves for many > many years (if ever), are uncertain, and can be susustained only by faith > and belief into the transcendent value of beauty and truth themselves. > > Anyone wishes to donate to the establishment of the new software > religion? > > --vadim > > From perfgeek at mac.com Thu Feb 23 22:12:31 2006 From: perfgeek at mac.com (rick jones) Date: Thu, 23 Feb 2006 22:12:31 -0800 Subject: [e2e] 0% NAT - checkmating the disconnectors In-Reply-To: <43FC9D43.7010800@reed.com> References: <20060222085720.6477C1A0214@smtp-1.hotpop.com> <43FC87C8.40706@isi.edu> <43FC9D43.7010800@reed.com> Message-ID: <2aec57312002b644e66402b7181a1075@mac.com> Not well thought out, and far from technical, likely pessimistic, and certainly quixotic, but it seems that what separates the "good old days" from the "bad new days" is money. To my fuzzy recollection, "in the beginning" few if any were trying to make money from/on the Internet. It was in broad handwaving terms, a medium of the geeks, by the geeks and for the geeks. People for whom it was not a job, not even a career, but a way of life. One basically shared by all the participants. Then some folks decided to make it user friendly and give it a GUI - the "WWW" - and it was all downhill from there. The Internet had taken its byte from the proverbial apple. I have to wonder if any work of mankind can grow and become ubiquitous without becoming tainted in some way. "Civilization" grew and begat bureaucracy and forms of government of varying palatability. Postal mail grew and begat junk mail. The telephone network grew and begat telemarketers. The Internet grew and begat what we've got today. Seems if you want to keep a next generation "clean" it has to remain small, impoverished, and uninteresting in the large. rick jones there is no rest for the wicked, yet the virtuous have no pillows - me From gds at best.com Thu Feb 23 23:56:53 2006 From: gds at best.com (Greg Skinner) Date: Fri, 24 Feb 2006 07:56:53 +0000 Subject: [e2e] 0% NAT - checkmating the disconnectors In-Reply-To: <2aec57312002b644e66402b7181a1075@mac.com>; from perfgeek@mac.com on Thu, Feb 23, 2006 at 10:12:31PM -0800 References: <20060222085720.6477C1A0214@smtp-1.hotpop.com> <43FC87C8.40706@isi.edu> <43FC9D43.7010800@reed.com> <2aec57312002b644e66402b7181a1075@mac.com> Message-ID: <20060224075653.A39283@gds.best.vwh.net> On Thu, Feb 23, 2006 at 10:12:31PM -0800, rick jones wrote: > Not well thought out, and far from technical, likely pessimistic, and > certainly quixotic, but it seems that what separates the "good old > days" from the "bad new days" is money. I'd like to argue that some things that we take for granted now didn't work so well in the "good old days." We now have mature and robust DNS and mail protocols; back then we had a myriad of transport and name resolution systems that required various types of sorcery to navigate. I could go on, but don't want to drift (further) off topic. --gregbo From Jon.Crowcroft at cl.cam.ac.uk Fri Feb 24 07:11:49 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 24 Feb 2006 15:11:49 +0000 Subject: [e2e] Caul for Pipers Message-ID: so after reading Yet Another Paper about a slightly faster fuzzy control theoretic ant routed logistikal neural feedback Big Elephantine Pipe new human-variant TCP, I reckon there's only one solution for all of poor us who have to review these things for conferences. We need a new Conference - lets pretend we had it and it would be called The Conference for Protocols (TCP) sponsored by the ACM (Another Conference Mistake) Papers would have to include something of the following Use of NS 2 (or 3) to simulate a single link/single router (don't ask why there's a router if there's only 1 link:) TCP friend or foe? Fairness or Foulness of Rate Adjustment Algorithm Ensemble behaviour of an orchestra of such beasties Effects of partial deployment of Especially Considerate Networks (ECN) Secure, Multicast and Mobile - TCP Westpoint Pseudocode for Pseudo-protocols Reproduceable Experiments Deprecated (RED) UCP-lite (cross layer optimisation of joint coded TCP/UDP protocol) TeraPIN - Towards Terabit TCP with Protocol In-core Networking Hop-by-skip flow control revisited A Dark Matter Model of Missing Packets Tetra-Chloro Phenol - Stamp Out Viruses in your Routers Quantum TCP and Covert Signaling Trading Packet Headers for Router Stock - Nasdaq Latest Quotes Label Switched Port Numbers The Land Slow Record for TCP - how long can your connection stay up and not send anything? NAT Abseiling for Beginners Amdahl's Law and Multicore processors and Optical I/O Moore's Law and Multicore processors and Google Your own suggestions for additional topics for this exciting new conference are welcome TCP - Be excellent! From imcdnzl at gmail.com Thu Feb 23 12:13:02 2006 From: imcdnzl at gmail.com (Ian McDonald) Date: Fri, 24 Feb 2006 09:13:02 +1300 Subject: [e2e] applcation layer!!!! In-Reply-To: <20060223104556.5723.qmail@webmail7.rediffmail.com> References: <20060223104556.5723.qmail@webmail7.rediffmail.com> Message-ID: > Hi all, > As the DOS attack issue is getting heated up in the group. I would like to divert your attention a bit. > As we know the current trends in the Internet technology points to an increasingly heterogeneous network consisting of links of vastly different characteristics. Satellite networks, WLANS, mobiles will be ubiquitous and an integral part of the future Internet. As we have seen all the layers of OSI model evolving , can anyone throw some light how application layer is evolving inorder to take into account the heterogenity of the network. > Is any changes in the application framework been proposed which can give a better perfomance taking into account the heterogenity of the network. > > I mean to say has anyone looked from the application point of view, or is it better to keep the application unaware of the medium. > > I'm sorry if the above question is irrelevant or may be stupid but atleast I would expect some comments.... > Hi there, I think that there can be improvements made by making the application aware of variables such as transmit rate, loss etc so the codecs or apps can make changes in a better way. I also think that there can be quite a bit done in the transport layer also. Here is an entry from my blog where I describe what I am currently doing: (Also my research proposal talks about this a bit if you want to read it - get it from my page mentioned in the URL in my signature). In my literature review I found a number of references to packet priority in regards to multimedia traffic. My particular interest is in real time applications e.g. VoIP, video conferencing. One method that I found was to split the traffic into layers and send the highest priority layer first. Another method was to have a ring buffer at the transport layer where packets could get pulled up until they were sent and replaced with more appropriate packets. This has had me thinking for a while now and I think that what I will do is send information about the packet along with the packet to the transport layer. This information will include: * type of packets (video channel (and layer if appropriate), audio channel, control) * expiry time For video packets it will include how many packets make up the frame, and which packet this is in the sequnce of that frame. Later on I will also put in a concept of layer also probably if rendering in a progressive manner. Audio and control packets should fit within one packet. The application would send using sendmsg instead of write to send this control information. The transport layer (DCCP in my first round of coding I imagine) would then send packets in the correct priority order basically following a set of rules something like: * if the packet has expired discard it. This time will actually include the RTT which it keeps track of so we can say "this packet must reach the destination within x msecs" * send control information first * send audio second * send video third. Check if the whole frame can be sent before the expiry time. If it can't and there is another video frame then discard and start sending that frame Obviously it will be a little bit more complicated than that but I think this is a reasonable approach and we should get more relevant data through as DCCP will know pretty exactly the state of the connection. In summary - get the transport layer to send the best packet next! -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand From mhufe at UDel.Edu Sat Feb 25 08:55:29 2006 From: mhufe at UDel.Edu (mhufe@UDel.Edu) Date: Sat, 25 Feb 2006 11:55:29 -0500 (EST) Subject: [e2e] applcation layer!!!! Message-ID: <20060225115529.ATE27726@ms2.nss.udel.edu> SCTP offers some interesting features that could make life a little easier at the application layer. A single association can contain multiple streams. So, audio could be packaged in one stream, video in another, and control on yet a third. There's also an extension called PR-SCTP (partial reliability). The sending application can specify a userful lifetime to the transport layer for a particular chunk of data. If the data isn't acknowledged within a specified time duration, the data is discarded. Multi-homing is another feature provided by SCTP. An association from one host to another can be made over multiple interfaces. That is, host A might have an ethernet interface and a wireless interface. Host B might two or more similar interfaces. An application on host A could form an association with an application on Host B through any combination of interfaces, determined at the transport layer. The original intent of multi-homing was fault tolerance. Data for an association is sent across a single interface pair under normal circumstances. If there is a failure anywhere along the path, then the association can continue exchanging data along an alternate path in a manner that can be transparent to the application, with the exception of the delays related to detecting the primary path failure. There's also some research being done in the area of Concurrent Multipath Transfer (CMT) using SCTP. For more information, check out this link: http://www.eecis.udel.edu/~amer/PEL/poc/index.html. - Mark Hufe Ian McDonald wrote: >> Hi all, >> As the DOS attack issue is getting heated up in the group. I would like to divert your attention a bit. >> As we know the current trends in the Internet technology points to an increasingly heterogeneous network consisting of links of vastly different characteristics. Satellite networks, WLANS, mobiles will be ubiquitous and an integral part of the future Internet. As we have seen all the layers of OSI model evolving , can anyone throw some light how application layer is evolving inorder to take into account the heterogenity of the network. >> Is any changes in the application framework been proposed which can give a better perfomance taking into account the heterogenity of the network. >> >> I mean to say has anyone looked from the application point of view, or is it better to keep the application unaware of the medium. >> >> I'm sorry if the above question is irrelevant or may be stupid but atleast I would expect some comments.... >> >> >> >Hi there, > >I think that there can be improvements made by making the application >aware of variables such as transmit rate, loss etc so the codecs or >apps can make changes in a better way. > >I also think that there can be quite a bit done in the transport layer >also. Here is an entry from my blog where I describe what I am >currently doing: (Also my research proposal talks about this a bit if >you want to read it - get it from my page mentioned in the URL in my >signature). > >In my literature review I found a number of references to packet >priority in regards to multimedia traffic. My particular interest is >in real time applications e.g. VoIP, video conferencing. > >One method that I found was to split the traffic into layers and send >the highest priority layer first. Another method was to have a ring >buffer at the transport layer where packets could get pulled up until >they were sent and replaced with more appropriate packets. > >This has had me thinking for a while now and I think that what I will >do is send information about the packet along with the packet to the >transport layer. This information will include: > > * type of packets (video channel (and layer if appropriate), audio >channel, control) > * expiry time > >For video packets it will include how many packets make up the frame, >and which packet this is in the sequnce of that frame. Later on I will >also put in a concept of layer also probably if rendering in a >progressive manner. > >Audio and control packets should fit within one packet. > >The application would send using sendmsg instead of write to send this >control information. > >The transport layer (DCCP in my first round of coding I imagine) would >then send packets in the correct priority order basically following a >set of rules something like: > > * if the packet has expired discard it. This time will actually >include the RTT which it keeps track of so we can say "this packet >must reach the destination within x msecs" > * send control information first > * send audio second > * send video third. Check if the whole frame can be sent before >the expiry time. If it can't and there is another video frame then >discard and start sending that frame > >Obviously it will be a little bit more complicated than that but I >think this is a reasonable approach and we should get more relevant >data through as DCCP will know pretty exactly the state of the >connection. > >In summary - get the transport layer to send the best packet next! >-- >Ian McDonald >Web: http://wand.net.nz/~iam4 >Blog: http://imcdnzl.blogspot.com >WAND Network Research Group >Department of Computer Science >University of Waikato >New Zealand > > From kunhuang at uga.edu Mon Feb 27 22:27:07 2006 From: kunhuang at uga.edu (Kun Huang) Date: Tue, 28 Feb 2006 01:27:07 -0500 Subject: [e2e] tcp connection timeout References: <20060225115529.ATE27726@ms2.nss.udel.edu> Message-ID: <013101c63c30$0008c7b0$2401a8c0@hk4> Hi, I recently got a TCP connection timeout error. If both side don't send packets for a long time while connection is open, is there a default time out to abort the connection? Thanks a lot! - Kun From lars.eggert at netlab.nec.de Tue Feb 28 00:06:37 2006 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Tue, 28 Feb 2006 09:06:37 +0100 Subject: [e2e] tcp connection timeout In-Reply-To: <013101c63c30$0008c7b0$2401a8c0@hk4> References: <20060225115529.ATE27726@ms2.nss.udel.edu> <013101c63c30$0008c7b0$2401a8c0@hk4> Message-ID: <6C8FE45E-0A6E-4ACF-B666-1AA8AB5FC6D7@netlab.nec.de> Hi, On Feb 28, 2006, at 7:27, Kun Huang wrote: > I recently got a TCP connection timeout error. > > If both side don't send packets for a long time while connection is > open, is there a default time out to abort the connection? draft-ietf-tcpm-tcp-uto-02.txt talks about this. http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-02.txt Lars -- Lars Eggert NEC Network Laboratories -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3686 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060228/0814a21d/smime.bin From shrin.krishnan at gmail.com Mon Feb 27 11:11:01 2006 From: shrin.krishnan at gmail.com (Srinivas Krishnan) Date: Mon, 27 Feb 2006 14:11:01 -0500 Subject: [e2e] application layer -SCTP!!!! Message-ID: SCTP does seem to provide on the outside a very nice interface borrowing congestion control from TCP and the concept of various streams. However, the experiences we had with SCTP are not too good, especially with the PR-SCTP. We at UNC-CH wanted a protocol that lets choose on the application layer conditions whether we wanted a fully reliable protocol or just a best-effort protocol. Unfortunately the 2 implementations of SCTP: SCTPLIB (a user level package) or the kernel level implementation in Linux do not fully support partial reliability or a way of making per packet/object decision of whether we wanted full reliability, partial etc. In the end we rolled out our own protocol based on UDP using TFRC as a congestion control algorithm (based it on the sender side). The protocol lets us choose whether we wanted to provide full reliability, partial reliability based on the application. We even have a module which does a form of congestion control in the application itself. This is for a video adaptation and hence based on latency we always do not need to send the next packet as the time for display on the client might have passed. I will describe some more of our work on video adaptation on a separate post. ********************************* Srinivas Krishnan Graduate Student Dept. Of Computer Science UNC-Chapel Hill ++++++++++++++++++++++++++++++++ Phone: **Office: (919) 962-1920 **Cell: (585)295-3359 Email: krishnan at cs.unc.edu, shrin.krishnan at gmail.com ++++++++++++++++++++++++ Web: www.cs.unc.edu/~krishnan ************************************** From faber at ISI.EDU Tue Feb 28 11:12:51 2006 From: faber at ISI.EDU (Ted Faber) Date: Tue, 28 Feb 2006 11:12:51 -0800 Subject: [e2e] tcp connection timeout In-Reply-To: <6C8FE45E-0A6E-4ACF-B666-1AA8AB5FC6D7@netlab.nec.de> References: <20060225115529.ATE27726@ms2.nss.udel.edu> <013101c63c30$0008c7b0$2401a8c0@hk4> <6C8FE45E-0A6E-4ACF-B666-1AA8AB5FC6D7@netlab.nec.de> Message-ID: <20060228191251.GA78860@hut.isi.edu> On Tue, Feb 28, 2006 at 09:06:37AM +0100, Lars Eggert wrote: > Hi, > > On Feb 28, 2006, at 7:27, Kun Huang wrote: > >I recently got a TCP connection timeout error. > > > >If both side don't send packets for a long time while connection is > >open, is there a default time out to abort the connection? > > draft-ietf-tcpm-tcp-uto-02.txt talks about this. That's for proposed new function. The behavior you see is documented in RFC 793 and RFC 1122. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060228/906d9c27/attachment.bin From perfgeek at mac.com Tue Feb 28 19:08:44 2006 From: perfgeek at mac.com (rick jones) Date: Tue, 28 Feb 2006 19:08:44 -0800 Subject: [e2e] tcp connection timeout In-Reply-To: <6C8FE45E-0A6E-4ACF-B666-1AA8AB5FC6D7@netlab.nec.de> References: <20060225115529.ATE27726@ms2.nss.udel.edu> <013101c63c30$0008c7b0$2401a8c0@hk4> <6C8FE45E-0A6E-4ACF-B666-1AA8AB5FC6D7@netlab.nec.de> Message-ID: <7c6c8c953be1dfbc2eecf487437b3279@mac.com> >> If both side don't send packets for a long time while connection is >> open, is there a default time out to abort the connection? > > draft-ietf-tcpm-tcp-uto-02.txt talks about this. > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-02.txt perhaps I read it too quickly, but it seems to be talking more about timeouts for when there is data outstanding rather than when the connection is idle. i also missed if it would abort or close the connection. presumably, there would be a way to retrieve the user timeout setting for a connection - doesn't that make this option usable as a covert channel? WRT the original question, IIRC there is nothing in the TCP spec that specifies a timeout for an idle connection. rick jones Wisdom teeth are impacted, people are affected by the effects of events From benbrah at auburn.edu Tue Feb 28 21:53:25 2006 From: benbrah at auburn.edu (Brahim Ben) Date: Tue, 28 Feb 2006 23:53:25 -0600 Subject: [e2e] tcp connection timeout Message-ID: <4404E2750200003A00009D60@TMIA1.AUBURN.EDU> Hi Kun, Some implementations of TCP implement a timer called Keepalive timer, once this timer goes off, one side will check even if the other side is still runnnig the connection, if no responding is received the connection is terminated. Best regards, Ben Brahim Taha >>> "Kun Huang" 02/28/06 12:27 AM >>> Hi, I recently got a TCP connection timeout error. If both side don't send packets for a long time while connection is open, is there a default time out to abort the connection? Thanks a lot! - Kun From benbrah at auburn.edu Tue Feb 28 21:54:33 2006 From: benbrah at auburn.edu (Brahim Ben) Date: Tue, 28 Feb 2006 23:54:33 -0600 Subject: [e2e] tcp connection timeout Message-ID: <4404E2B90200003A00009D64@TMIA1.AUBURN.EDU> Hi Kun, Some implementations of TCP implement a timer called Keepalive timer, once this timer goes off, one side will check even if the other side is still runnnig the connection, if no responding is received the connection is terminated. Best regards, Ben Brahim Taha >>> "Kun Huang" 02/28/06 12:27 AM >>> Hi, I recently got a TCP connection timeout error. If both side don't send packets for a long time while connection is open, is there a default time out to abort the connection? Thanks a lot! - Kun From sampad_m at rediffmail.com Tue Feb 28 22:52:12 2006 From: sampad_m at rediffmail.com (sampad mishra) Date: 1 Mar 2006 06:52:12 -0000 Subject: [e2e] tcp connection timeout Message-ID: <20060301065212.25342.qmail@webmail6.rediffmail.com> On Wed, 01 Mar 2006 rick jones wrote : > >>>If both side don't send packets for a long time while connection is open, is there a default time out to abort the connection? When TCP has not received a segment for more than one retransmission timeout(ie the idle time), cwnd is reduced to the value of the restart window (RW) before. RW = min(IW, cwnd) . IW, the initial value of cwnd, MUST be less than or equal to 2*SMSS bytes and MUST NOT be more than 2 segments. Refer "rfc-2581" Regards, Sampad Mishra, Indian Institute of Science, Bangalore. >> >>draft-ietf-tcpm-tcp-uto-02.txt talks about this. >> >>http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-02.txt > >perhaps I read it too quickly, but it seems to be talking more about timeouts for when there is data outstanding rather than when the connection is idle. i also missed if it would abort or close the connection. > >presumably, there would be a way to retrieve the user timeout setting for a connection - doesn't that make this option usable as a covert channel? > >WRT the original question, IIRC there is nothing in the TCP spec that specifies a timeout for an idle connection. > >rick jones >Wisdom teeth are impacted, people are affected by the effects of events > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060301/200be97e/attachment.html From sampad_m at rediffmail.com Tue Feb 28 23:07:13 2006 From: sampad_m at rediffmail.com (sampad mishra) Date: 1 Mar 2006 07:07:13 -0000 Subject: [e2e] tcp connection timeout Message-ID: <20060301070713.9996.qmail@webmail30.rediffmail.com> On Wed, 01 Mar 2006 Brahim Ben wrote : >Hi Kun, > >Some implementations of TCP implement a timer called Keepalive timer, >once this timer goes off, one side will check even if the other side is >still runnnig the connection, if no responding is received the >connection is terminated. Ben is right.... You can refer RFC 1122 for keep alive explanation. Keep alive timers are usually congigurable and are usually pretty high . However, I'm not aware whether current TCP's implement it or not. Regards, Sampad Mishra, Indian Institute of Science, Bangalore. >Best regards, > >Ben Brahim Taha > > > > >>> "Kun Huang" 02/28/06 12:27 AM >>> >Hi, > >I recently got a TCP connection timeout error. > >If both side don't send packets for a long time while connection is >open, is >there a default time out to abort the connection? > >Thanks a lot! > >- Kun > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060301/abff8d42/attachment.html From lars.eggert at netlab.nec.de Tue Feb 28 23:59:11 2006 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Wed, 1 Mar 2006 08:59:11 +0100 Subject: [e2e] tcp connection timeout In-Reply-To: <20060228191251.GA78860@hut.isi.edu> References: <20060225115529.ATE27726@ms2.nss.udel.edu> <013101c63c30$0008c7b0$2401a8c0@hk4> <6C8FE45E-0A6E-4ACF-B666-1AA8AB5FC6D7@netlab.nec.de> <20060228191251.GA78860@hut.isi.edu> Message-ID: <9AD2BA2D-3059-4C75-B26F-2114F29B5E4F@netlab.nec.de> On Feb 28, 2006, at 20:12, Ted Faber wrote: > On Tue, Feb 28, 2006 at 09:06:37AM +0100, Lars Eggert wrote: >> On Feb 28, 2006, at 7:27, Kun Huang wrote: >>> I recently got a TCP connection timeout error. >>> >>> If both side don't send packets for a long time while connection is >>> open, is there a default time out to abort the connection? >> >> draft-ietf-tcpm-tcp-uto-02.txt talks about this. > > That's for proposed new function. The behavior you see is > documented in > RFC 793 and RFC 1122. Right; the intro has an overview of the existing functionality though. (I should have included this in my original mail.) Lars -- Lars Eggert NEC Network Laboratories -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3686 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060301/27db6505/smime.bin From imcdnzl at gmail.com Tue Feb 28 13:07:38 2006 From: imcdnzl at gmail.com (Ian McDonald) Date: Wed, 1 Mar 2006 10:07:38 +1300 Subject: [e2e] application layer -SCTP!!!! In-Reply-To: References: Message-ID: On 2/28/06, Srinivas Krishnan wrote: > SCTP does seem to provide on the outside a very nice interface > borrowing congestion control from TCP and the concept of various > streams. However, the experiences we had with SCTP are not too good, > especially with the PR-SCTP. We at UNC-CH wanted a protocol that lets > choose on the application layer conditions whether we wanted a fully > reliable protocol or just a best-effort protocol. Unfortunately the 2 > implementations of SCTP: SCTPLIB (a user level package) or the kernel > level implementation in Linux do not fully support partial reliability > or a way of making per packet/object decision of whether we wanted > full reliability, partial etc. > > In the end we rolled out our own protocol based on UDP using TFRC as a > congestion control algorithm (based it on the sender side). The > protocol lets us choose whether we wanted to provide full reliability, > partial reliability based on the application. We even have a module > which does a form of congestion control in the application itself. > This is for a video adaptation and hence based on latency we always do > not need to send the next packet as the time for display on the client > might have passed. I am doing a similar thing but basing it in the transport layer. It will check whether the packet is past expiry time before sending and will also weight control packets higher than audio with video being the lowest. I am working with using DCCP CCID3 on Linux at present which is similar in performance I would assume to UDP using TFRC as CCID3 is TFRC based. Have you looked at DCCP? You might be able to choose whether you want reliable or unreliable using a mixture of switching between TCP and DCCP or were you wanting to switch midstream? > > I will describe some more of our work on video adaptation on a separate post. Will be interested in seeing. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand From mss at us.ibm.com Tue Feb 28 18:35:24 2006 From: mss at us.ibm.com (Mark S Squillante) Date: Tue, 28 Feb 2006 21:35:24 -0500 Subject: [e2e] ACM SIGMETRICS / IFIP WG 7.3 Workshop on MAthematical performance Modeling and Analysis Message-ID: CALL FOR ABSTRACTS -- MAMA 2006 The Eighth Workshop on MAthematical performance Modeling and Analysis MAMA 2006 June 27, 2006 Saint-Malo, France Held in conjunction with SIGMETRICS/Performance 2006 http://www.cs.wm.edu/sigm06/ Sponsored by ACM SIGMETRICS and IFIP Working Group 7.3 The complexity of computer systems, networks and applications, as well as the advancements in computer technology, continue to grow at a rapid pace. Mathematical analysis, modeling and optimization are playing an important role in research studies to investigate fundamental issues and tradeoffs at the core of performance problems in the design and implementation of complex computer systems, networks and applications. The Eighth Workshop on MAthematical performance Modeling and Analysis (MAMA 2006) seeks to bring together researchers working on the mathematical, methodological and theoretical aspects of performance analysis, modeling and optimization. It is intended to provide a forum at SIGMETRICS/Performance conferences for talks on early research in the more mathematical areas of computer performance analysis. These talks tend to be based on very recent research results (including work in progress) or on new research results that will be otherwise submitted only to a journal (or recently have been submitted to a journal). Thus, part of the goal is to complement and supplement the SIGMETRICS/Performance Conference program with such talks without removing any theoretical contributions from the main technical program. This year's workshop will be held on June 27 (before the main SIGMETRICS/Performance technical program). In addition to the presentation of extended abstracts, the workshop will include time for informal technical discussions among the speakers and attendees. SUBMISSION INFORMATION April 24, 2006: Abstract Submission Deadline May 8, 2006: Acceptance Notification May 22, 2006: Final Abstracts for Workshop Sept 1, 2006: Final Extended Abstracts for PER MAMA 2006 encourages the submission of abstracts describing early research on the general mathematical, methodological and theoretical aspects of performance analysis, modeling and optimization. Authors are asked to submit 3-4 page, single-column abstracts before the above deadline. Abstracts should be submitted electronically, as e-mail attachments, to mss at us.ibm.com. Postscript or PDF is preferred, although other arrangements can be made by contacting Mark Squillante (mss at us.ibm.com). Submissions will be reviewed by the MAMA program committee, from which a number of abstracts will be selected for inclusion in the workshop program. A version of the abstracts will be provided at the workshop. Extended versions of the abstracts will appear in a special issue of Performance Evaluation Review (PER), with a due date after the workshop making it possible for authors to incorporate the results of, or simply mention, any relevant discussions at the workshop. Note that there are no copyright issues with PER, and thus authors will have complete freedom to submit their work elsewhere. Additional information about the MAMA 2006 Workshop can be found at: http://www.cs.wm.edu/sigm06/MAMAindex.html For more information about the workshop, please contact Mark Squillante (mss at us.ibm.com). Additional information about the SIGMETRICS/Performance 2006 Conference can be found at: http://www.cs.wm.edu/sigm06/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060228/4c20627f/attachment.html