RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00

> Just to clarify, I was not talking about the ECN nonce which, as you
> rightly say, is intended to address a different problem (the concealing
> of ECN marks). I was actually referring to a solution presented by
> Stefan Savage et al in the paper "TCP Congestion Control with a
> Misbehaving Receiver". In this paper they present two versions of a
> transport layer nonce which they call the "Singular Nonce" and
> "Cumulative Nonce". We do look at the ECN nonce in the actual draft
> since that claims to protect against the two attacks our test is
> designed to identify.

Hm, I always thought that the nonce in this paper by Stefan Savage
is the ancestor of the ECN nonce, but maybe there's a small
but significant difference there

> Thanks for the pointer as to the slightly surprising wording in RFC2581.
> As far as I can tell everyone seems to assume this was a MUST anyway...!

...and I would expect most implementations to conform with this
interpretation - so it would be interesting to learn the reasoning
behind the SHOULD. This is not the first time that I'm surprised
by something in RFC 2581, and so far, it always turned out that
there was a good reason for everything. It's just full of
such intricacies  :)

Cheers,
Michael

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm