Bug 2264

Summary: Possibility to setup Initial Sequence Number (ISN)
Product: ns-3 Reporter: Matthieu Coudron <mattator>
Component: tcpAssignee: natale.patriciello
Status: PATCH PENDING ---    
Severity: enhancement CC: ns-bugs, tomh
Priority: P5    
Version: ns-3-dev   
Hardware: PC   
OS: Linux   
See Also: https://www.nsnam.org/bugzilla/show_bug.cgi?id=1529
Attachments: randomization patch
randomization patch (v2)

Description Matthieu Coudron 2016-01-13 12:31:33 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.
Comment 1 Tom Henderson 2016-02-16 00:53:13 EST
Created attachment 2275 [details]
randomization patch
Comment 2 Tom Henderson 2016-02-16 00:56:26 EST
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
Comment 3 Matthieu Coudron 2016-02-16 06:18:59 EST
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.
Comment 4 natale.patriciello 2016-02-16 06:25:03 EST
(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.
Comment 5 Tom Henderson 2016-02-16 10:20:42 EST
(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.
Comment 6 Tom Henderson 2016-02-16 18:28:16 EST
Created attachment 2276 [details]
randomization patch (v2)