Bugzilla – Bug 2264
Possibility to setup Initial Sequence Number (ISN)
Last modified: 2016-02-16 18:28:16 EST
Ns3 uses an ISN of 0 for its TCP connections. I wonder if it's problematic when interacting with a linux stack (as in DCE, I believe Nat experienced it) ? An ISN of O can be problematic when analyzing ns3 pcap traces (wireshark used to chock on that but I fixed it upstream). As for MPTCP, the ISN must match part of the hash of a key not to disturb wireshark. As I use wireshark for my analysis, I've implemented in a branch random/chosen ISN. The current implementation use temporary variable but I think I can do without them. Once SND.UNA get merged (TxUnack), I will update my patch.
Created attachment 2275 [details] randomization patch
Attached is the current patch I'm testing; I would hold it a bit longer but there is a TCP meeting tomorrow so I'll post what I have. The main issue I haven't looked into yet is that the tcp-zero-window-test runs forever, for some reason, and has to be forcefully stopped. The other FAILed tests have some dependency on the value of ISN being 0. The routing-aodv-regression traces can simply be updated, but the other TCP tests that rely on ISN being 0 may have to be reworked. List of FAILed tests: routing-aodv-regression tcp-fast-retr-test tcp-rto-test List of CRASHed tests: tcp-zero-window-test
In the MPTCP case, ISN is not random but this could work with this (the mptcp socket can override the ISN later with SetInitialSequence). I suppose it would give more flexibility to propose the ISN generator as an Attribute, this way people can keep the current behavior and propose a Constant Generator or generate ISN with different levels of entropy to simulate attacks. Dunno if TxUnack is in master's, but initial sequence number should also update it when it comes.
(In reply to Matthieu Coudron from comment #3) > I suppose it would give more flexibility to propose the ISN generator as an > Attribute, this way people can keep the current behavior and propose a > Constant Generator or generate ISN with different levels of entropy to > simulate attacks. I really like such idea.. > Dunno if TxUnack is in master's, but initial sequence number should also > update it when it comes. I don't think I've got it.. anyway, the patches is missing updating also m_recover variable. For the tests, yes they rely on ISN being 0, but updating them is easy.
(In reply to natale.patriciello from comment #4) > (In reply to Matthieu Coudron from comment #3) > > I suppose it would give more flexibility to propose the ISN generator as an > > Attribute, this way people can keep the current behavior and propose a > > Constant Generator or generate ISN with different levels of entropy to > > simulate attacks. > > I really like such idea.. +1, this could also sidestep redoing some of the tests that are failing. I'll make this change. > > > > Dunno if TxUnack is in master's, but initial sequence number should also > > update it when it comes. > > I don't think I've got it.. anyway, the patches is missing updating also > m_recover variable. I'll have a look at the other variables; agreed. > > For the tests, yes they rely on ISN being 0, but updating them is easy.
Created attachment 2276 [details] randomization patch (v2)