Subject: [Tsvwg] Some Questions on TCP.

From: "lokesh" <[email-masked]>
Date: Wed, 26 Sep 2001 15:25:19 +0530

Hello all,

I have got some questions regarding Operation of TCP.
can anyone among you clarify it?

1] 
Tcp layer, when a pkt arrives,  first it performs the check sum calculation,
 where it takes the tcp data, tcp header + pseudo header for consideration,
 my doubt is why it calculates  checksum for pseudo header.
 the  parameters in pseudo header source addr, dest addr , protocol
 which are checked by ip layer so why again we are
doing checksum on these parametrs, is it not reduntant????

in his book on TCP/IP Richard Stevens writes that :- It is double protection checking,
 that is whether the pkt reached to correct host and whether the ip handed over the pkt to
correct layer (ie, tcp/udp..), if it has to see these, then why to only
calculate the checksum why not simply check the parameters (source addr,dest
addr,protocol)

the very fact that you've got the packet at tcp verifies that it has reached correct host.
and if you want to be sure that it has come from the source it says, anyone who tampered packet 
in the middle would definitely have calculated/updated checksum  correctly, so the surety is provides on source address
cant be relied  right?

 doesn't it look  like just calculating checksum over tcp header and data would be  more efficient than
again taking parameters from IP and constructing pseudoheader and performing  checksum calculation?

2]

is SYN segment carries any seq number?

that is I will give You an example so that it will be clear

   suppose A wants to communicates with B
   so A will send a syn segment (say seq = 100) to B
   and B will respond with ACK segment that is (ack=101) that is B is
   expecting a sequence  number of 101th byte.

that means seq number 100 is taken by SYN segment that is it has occupied i
byte.

in the similar lines does FIN segment carries any seq. number?

3]
 if the 32 bit sequence number wraps around then how the tcp state 
moves  I mean that how we are going to decide that  whether to accept the incoming
packet or not? for ex :

say a segment with 1000 bytes you have to send and the sequence number is close to
complete the max. 32bit value
["A new acknowledgment (called an "acceptable ack"), is one for which
  the inequality below holds:

    SND.UNA < SEG.ACK =< SND.NXT "   page 25 in rfc 793 ]
so how the pkt movement will be?????

4] TCP determines and eliminates duplicates by looking into seq numbers, if that is true.. pls 
    consider following scenario..

[ISS = Initial Segment Seq no according to RFC793]

.   During simulataneous connection establishment.
    
          Eg : TCP A                                                  TCP B
           ISS = 1000                                           ISS =5000
           D.Port =999                                         D.Port =888
           S.Port =888                                         S.port =999

           1.    SEQ = 1000  ------SYN segment-------------->>>>
                              <<<----SYN segment----------------- SEQ=5000

                         (At same time both syn's are sent and received)
           2.    SEQ = 1000 , ACK = 5001 -----SYN,ACK seg--->>
                              <<<------SYN,ACK seg  SEQ = 5000 , ACK = 1001

           ESTB                                                  ESTB

           So segment  from A to B (seq =1000) is received twice by B but 
           B does not consider segment 2 from A to B as a duplicate.WHY so ??
           This is according to RFC793 Pg 32 fig 8.

if you could read till here, thanks for your labour :-) 

 If you can put little more labour to answer,  I' ll be more thankful to you  then :)

Thanks
Lokesh.

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Sep 2001 08:51:50 -0700

>  can anyone among you clarify it?

Hi, Lokesh,

I followed your exchanges on the IPSEC mailing list. The questions you 
raise below have some somewhat subtle issues, which is why I am posting 
a general response. Note however that most (except the checksum issue) 
are already addressed in RFC793.

I encourage you to review the RFC and the Stevens book more carefully, 
especially on questions of basic operation.

Joe

> doing checksum on these parametrs, is it not reduntant????

The IP checksum verifies the address on the packet is valid.

The TCP checksum verifies that the body of the packet is valid,
AND that it has been delivered to the proper connection.

Accepting TCP data to the wrong connection corrupts the protocol. Since 
the connection is specified by the port pair AND the source/dest 
address, and the latter are not copied into the TCP header, they must be 
included from the IP header.

> calculate the checksum why not simply check the parameters (source addr,dest

Read this as "correct CONNECTION" (host and layer). On a single-IP'd 
host, this doesn't mean much, but remember, all network-connected hosts 
MUST have at least two valid IP addresses (X.X.X.X and 127.0.0.1).

> the very fact that you've got the packet at tcp verifies that it has 

Yes, but which one - X.X.X.X or 127.0.0.1 ? Or worse for multihomed hosts.

> in the middle would definitely have calculated/updated checksum 
> correctly, so the surety is provides on source address
> cant be relied  right?

The checksum checks errors; it doesn't prevent tampering.

> and performing checksum calculation?

IP checksum is very quick- including the IP header is a very small 
overhead.

> is SYN segment carries any seq number?

RFC793 pgs 16 and 26.
..
 > in the similar lines does FIN segment carries any seq. number?

RFC793 pgs 25 and 26, as well as
..
 > moves  I mean that how we are going to decide that  whether to accept

See RFC-793 page 24. All sequence number math is modulo arithmetic.

>            This is according to RFC793 Pg 32 fig 8.

You forgot to indicate the endpoint states. Here is the figure, in total:

       TCP A                                            TCP B
   1.  CLOSED                                           CLOSED
   2. SYN-SENT     --> <SEQ=100><CTL=SYN>              ...
   3.  SYN-RECEIVED <-- <SEQ=300><CTL=SYN>              <-- SYN-SENT
   4.               ... <SEQ=100><CTL=SYN>              --> SYN-RECEIVED
   5.  SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
   6.  ESTABLISHED  <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
   7.               ... <SEQ=101><ACK=301><CTL=ACK>     --> ESTABLISHED

                 Simultaneous Connection Synchronization
                                Figure 8.

The packets are considered different, even with the same SEQ number, 
because the endpoint state differs.

--

Joe

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "lokesh" <[email-masked]>
Date: Fri, 28 Sep 2001 17:03:51 +0530

Hi Joe,

Thanks for answering, I got some more follow up queries from your answers..
they appear at correct places in the
mail below.. please clarify it.
Thanks
Lokesh.
----- Original Message -----
From: "Joe Touch" <[email-masked]>
To: "lokesh" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 26, 2001 9:21 PM
Subject: Re: [Tsvwg] Some Questions on TCP.

> The checksum checks errors; it doesn't prevent tampering.
In that case why we are doing checksum? why not CRC? does cksum has an edge
over CRC?
what was basic reason for choosing checksum instead of CRC at tcp/ip
layers.?

> See RFC-793 page 24. All sequence number math is modulo arithmetic.

Just consider the scenario,
A and B are in connected state, suppose A sends seg with seq no 500 with 200
bytes of data,
now B will give an ack=700 seq=1000. this is normal situvation,
it may so happen that, B has got to reduce its window size suddenly that it
can acknowledge only 100 bytes
and sends an ack=600 seq=1000, then A will send next segment with seq=600
and some X number of bytes
correcly fitting into B's changed window size,  Assuming that
between A and B there exists a hyperchannel with MTU 65536 [future
possibility of such links can't be dismissed
 so is the buffer sizes at TCP layer]
and A and B have negotiated window size 70,000, then A will send a large
amount of data , there is a chance of
seq number wrap around, then how B will behave , what ack number will it
send to A?[assuming A has sent 65536 bytes]
will it send 0? (wrapped seq number?)

> >           Eg : TCP A
TCP B
> >            ISS = 1000                                           ISS
=5000
> >            D.Port =999                                         D.Port
=888
> >            S.Port =888                                         S.port
=999
> because the endpoint state differs.

In that case, while determining duplicate segments, we have to take the
states of tcp also in account?
as for as I know in RFC 793 this point is nowhere mentioned, if you have any
RFC stating that, can you suggest me
its number?