From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id A2F3E21F08F for ; Thu, 14 Jun 2012 00:22:54 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Sf4OI-0003Cb-LD for bloat@lists.bufferbloat.net; Thu, 14 Jun 2012 09:22:50 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx5.uio.no with esmtp (Exim 4.76) (envelope-from ) id 1Sf4OI-0003wd-6O for bloat@lists.bufferbloat.net; Thu, 14 Jun 2012 09:22:50 +0200 Message-ID: <4FD9914A.2000509@ifi.uio.no> Date: Thu, 14 Jun 2012 09:22:50 +0200 From: Michael Welzl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 22 sum msgs/h 6 total rcpts 20684 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1E28EBA2E6CE74AFC1E25133C142B18068A51BA6 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 8630 max/h 20 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [Bloat] mosh, ecn, and diffserv marking X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 07:22:55 -0000 Hi, On 6/14/12 5:02 AM, Dave Taht wrote: > This is a discussion of the innovative new partial ssh replacement, mosh, > which is documented here: > > http://mosh.mit.edu/ Looks cool to me! > My principal concern with enabling ECN in mosh was sites that would > filter out udp packets marked such entirely, so that they would not > reach their destination. Thus far, in my limited testing (and yours), > that seems not to be the case. > > If it were, I would recomend a backoff step for mosh's packets - > reverting to not having ECN marking after a lossy period, and > attempting to renable after recovery. This might still be a good > idea... I have this recurring thought that people should find ways to *try* ECN and back-off from it after a while instead of disabling it altogether. Maybe there is a way to sneak this functionality into TCP somehow... anyway, it's not a part of the current spec. What's interesting here is that this sounds as if you're trying to come up with this functionality for a UDP-based application, in user space. I like that, I think this is the right approach for ECN *in general*, not just for Mosh! >> But I'm a little concerned about the security implications here -- I don't >> want a bad guy to be able to sniff one packet from us and then replay it a >> million times with ECN set to cause a DoS. (snip) > Have you seen anybody discuss the appropriate use of ECN in a > security-sensitive transport protocol? TCP does not seem worried about this > DoS. > Oh brave new world that has such protocols in it! Perhaps what it would help to try to understand *why* this is of no concern in TCP? First of all, TCP doesn't do ECN on retransmits, i.e. it is only applied to new packets. Second, TCP reacts to loss or ECN only once per RTT. With TCP, the described replay attack would require the use of correct sequence numbers, and take effect only once per RTT. However, I think that the key issue is the following: IF you're able to construct a million correct looking packets and inject it into the TCP stream, ECN is the least of your problems (you could just as well inject RST, FIN, you name it). Yes, people have been looking into these issues too, long debates in TCPM, see http://datatracker.ietf.org/wg/tcpm/ for some documents. One ECN-specific concern that was addressed is that it's often in the interest of the receiver, but not the sender, to lie about ECN and simply cheat (reflect "nonono, no congestion at all" back to the sender). This is addressed by RFC3540, which is experimental and not really used. Out of that box, take what you like, I'd say! :-) I think that it would actually be nice to have an RFC that gives recommendations on how ECN should be used by UDP based applications. Strange that this isn't a part of RFC 5405? Maybe an update of this one would be appropriate. Cheers, Michael