Patient Clarification Needed - TCP Seq and Ack Numbers, Do I Have This Right?

[Miscbrah]

Okay, for some reason I'll get my head around this and then I'll casually be reading something days later which makes me doubt I have really got this.

 

So yeah, if I just brain dump here and anyone feels like picking through it I'll be very grateful.

 

I did the following in MSPaint:

 

http://i1236.photobucket.com/albums/ff441/TerrifyingGiantSquid/seqack_zps115a961e.jpg

 

Packet 1>2 is "Hello! Pls talk to me, that ok?" SYN flag set. Seq and Ack did nothing yet.

 

Packet 2<3 is "OMG hi we can talk, that ok?" SYN and ACK flags set, Ack is 1 because that's the acknowledgement of that first packet.

 

Packet 3>4 is "OMG let's talk then!" ACK flag set, Ack is still 1, but that previous Ack=1 means Seq is now 1. No bigger as there's actually no 'data' just flags.

 

Packet 4<5 is "LOOL here's your first bunch of data!" which is 100 bytes in size.

 

Packet 5>6 (this is where I start to fall down) is "OMFG thanks. Here's some data for you. I need part 101 next" The Seq is STILL 1 at this point, but I'm not 100% on why... Anyway, the Ack is now 101 because the last packet it got was 100 bytes in length, so the 101 is saying "I got 100 bytes. That number of bytes I added to the previous Seq number, so this now shows you how many I got, by my new Ack number, which is the Seq number I need NEXT from you in the stream of stuff we're sending ."

 

Packet 6<7 "Okay, my Seq is 101. This means I'm recognising that I got your Ack of 101 last time. Also, my Ack is now 131, which means I got YOUR Ack of 101 and ALSO got 30 bytes in the last packet. AND TO BOOT HERE'S 200 bytes OF F-ING DATA!"

 

Packet 7>8 "Right, my Seq is 131 because that's what you wanted from your last Ack number. I got 200 bytes and added that to the last Ack number, so next I'll need part 331 of the sequence, so here's the Ack number 331. Oh and here is some data for YOU, to the tune of 20 bytes because we're windowing like retards here.

 

Packet 8>9 "Kewl, I'm replying with Seq=331 because that's what you wanted from your last Ack, I'm recognising your last packet in bytes plus your last Ack, to give me the Seq number of the NEXT thing I'll need which is my Ack=351, and here's your 100 bytes."

 

...blah blah.

 

As you can see, I've TRIED to put it in plain English, but am I going wrong anywhere? If so, where?

 

Thanks for the help!

[Geoff]

You are correct but only for relative TCP SEQ/ACK numbers. Additionally you've not considered four way handshakes.

[Miscbrah]

Thanks Geoff!!!!

 

Um, what are these relative TCP SEQ/ACK numbers? Do you mean only for the rather simplistic example I've made, where there's one instance of to/fro I've given? Or is that something else?

 

Second 'um' is that yes I've not considered four way handshakes. What are those?

 

...I have this feeling the answer to BOTH of those is 'carry on with your CCNA until you hit those' and, if so, can I rest easy in that I'm at least getting the basics and going in the right direction?

 

Again, cheers.

[catch21]

The next host name I'm going to use is definately "Docker".

[Miscbrah]

The next host name I'm going to use is definately "Docker".

 

I have no idea why but I'm pleased for you.

[Geoff]

Thanks Geoff!!!!

 

Um, what are these relative TCP SEQ/ACK numbers? Do you mean only for the rather simplistic example I've made, where there's one instance of to/fro I've given? Or is that something else?

 

Second 'um' is that yes I've not considered four way handshakes. What are those?

 

...I have this feeling the answer to BOTH of those is 'carry on with your CCNA until you hit those' and, if so, can I rest easy in that I'm at least getting the basics and going in the right direction?

 

Again, cheers.

 

If you are looking at a connection setup in Wireshark it will show you relative seqence numbers (unless you tell it not to) which means the sequences numbers start from 0 at the first SYN. Depending on the OS, it might actually be using any number as the start sequence number (as an aside, this is an important 'fingerprint' in OS detection used in software such as NMap).

 

A Four way handshake is where one system rejects the proposed sequence number in the inital SYN and sets its own, to which the other agrees. So there's just an extra step basically.

[Miscbrah]

If you are looking at a connection setup in Wireshark it will show you relative seqence numbers (unless you tell it not to) which means the sequences numbers start from 0 at the first SYN. Depending on the OS, it might actually be using any number as the start sequence number (as an aside, this is an important 'fingerprint' in OS detection used in software such as NMap).

 

A Four way handshake is where one system rejects the proposed sequence number in the inital SYN and sets its own, to which the other agrees. So there's just an extra step basically.

 

Ah right! So this is the part I've read about, where the first seq number isn't really 0, it's some supposedly random number between 0 - 4294967297 but there are ways of telling what any OS might spit out at a given time.

 

I shall look at four way handshakes, or await those in my course.

 

Docker! I mean thanks!

[Geoff]

Ah right! So this is the part I've read about, where the first seq number isn't really 0, it's some supposedly random number between 0 - 4294967297 but there are ways of telling what any OS might spit out at a given time.

 

Speaking of time, some OS's use an encoded version of the current date/time as the sequence number, so it's possible to use them as an alternative to NTP. Other OS's use the number of seconds since boot up, so you can determine it's uptime. This is generally frowned upon these days, as guessable sequence numbers makes the connection hijackable.

Edited May 2, 2013 by Geoff