From: Dario Ciccarone (dciccaro) (dciccaro@cisco.com)
Date: Sat Jul 21 2007 - 10:10:49 EDT
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
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:57 EDT