RE: First TCP packet

["Dario Ciccarone (dciccaro)" <dciccaro () cisco com>]

The TCP datagram travels inside an IP packet, which would then be
encapsulated in some kind of L2 frame. Let's start by using the right
names :)

Generically speaking, the only thing that should change in route from A
to B should be the TTL on the IP Header. This assumes both the source
host and destination being directly connected to the Internet (no
firewalls/load balancers/others in the path) and no SP doing
QoS/rewriting headers.

That said, some of the things that might change in route, depending of
the combination of devices between source and destination:

IP Header:

* Version: doesn't change
* IP Header length - might change - if a firewall in the path
drops/removes IP options
* TOS - might change if a device in the path is rewriting it for QoS
purposes
* Total length (affected by (1))
* IPID: never heard of anyone doing IPID randomization - but you could
conceivably do so, and hence it would change
* Flags: can change if an intermediate device has to fragment the
datagram
* Fragment offset: can change if packet has been fragmented
* TTL: would certainly change ;)
* Protocol: doesn't change
* Header checksum: might change if any of the other possible changes
happen. I don't remember (and I'm feeling too lazy right now) which
fields are included into the checksum - check the RFC.
* Source IP address: might change - think NAT
* Destination IP address: might also change. Imagine a server farm
behind a load balancer - one DNS record (www.example.com) might actually
translate to N machines
* Options: as said, might change depending of devices on the path


TCP header:
* Source port: might change if NAT/specially PAT in the path
* Destination port: might be changed at destination - again, load
balancer, firewall
* Sequence number: might change - load balancers, firewalls performing
SEQ number randomization
* ACK number: same as sequence number - both might be doing SEQ number
randomization ;)
* Data offset: might change if firewall/other device adds/drops TCP
options
* Reserved: shouldn't change ;)
* Control bits: shouldn't change, but I can imagine a device setting
PSH. Might change
* Window: might change - host itself might change it, devices in the
path
* Checksum: might change depending on other fields changing
* Urgent pointer: makes sense if URG set - shouldn't change (IMHO :))
* Options: might change depending on devices on the path as we said
before
* padding: again, might change depending on previous
* data: shouldn't change from source/destination point of view - might
change while in transit between end hosts (think transparent
compression)

Almost everything can change. You would at least need a capture from
both ends - but if firewalls/load balancers/transparent compression is
changing stuff in the path, you might not see it (unless you sniff at
the entry and exit interface of each intermediate hop ;))

Good luck.

Dario


> -----Original Message-----
> From: listbounce () securityfocus com 
> [mailto:listbounce () securityfocus com] On Behalf Of 
> va.pentest () gmail com
> Sent: Saturday, July 21, 2007 3:11 AM
> To: pen-test () securityfocus com
> Subject: First TCP packet
>
> Hi Friends,
>
>
>      Somebody please explain me the following:
>
>
> A client and server are seperated by 5 HOPS. When I send a 
> TCP syn packet from client to server,
>
> What are the parameters that changes in a tcp packet by the 
> time the packet reaches server.
>
> I just want to know the changes happened to the first packet. 
>
>
> How to to test/check this with Wireshark.  
>
>
> Thanks
>
> kpr
>
> --------------------------------------------------------------
> ----------
> This list is sponsored by: Cenzic
>
> Need to secure your web apps NOW?
> Cenzic finds more, "real" vulnerabilities fast.
> Click to try it, buy it or download a solution FREE today!
>
> http://www.cenzic.com/downloads
> --------------------------------------------------------------
> ----------

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!

http://www.cenzic.com/downloads
------------------------------------------------------------------------