[Bloat] mosh, ecn, and diffserv marking

[Michael Welzl]

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