RE: First TCP packet

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@xxxxxxxxxxxxxxxxx
[mailto:listbounce@xxxxxxxxxxxxxxxxx] On Behalf Of
va.pentest@xxxxxxxxx
Sent: Saturday, July 21, 2007 3:11 AM
To: pen-test@xxxxxxxxxxxxxxxxx
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
------------------------------------------------------------------------

Relevant Pages

  • alt.2600 FAQ Revision .014 (2/4)
    ... One type of firewall is the packet filtering firewall. ... Dropping packets instead of rejecting them greatly increases the time required to scan your network. ... Port scanning UDP ports is much slower than port scanning TCP ports. ... Chartreuse Use the electricity from your phone line Cheese Connect two phones to create a diverter Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • Re: NDIS passthru packet redirection
    ... I solved this with adjusting the TCP checksum. ... Now I must redirect the answer packet to the calling application. ... TCP header or TCP data isn't changed, the you don't need to update the TCP ...
    (microsoft.public.development.device.drivers)
  • Re: jailed "system" needs IPV4 access
    ... see if the ACK flag is set on a tcp packet. ... the keep-state option just ... 00500 deny log ip from 192.160.1.0/24 to any in via dc1 ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Incoherent E-mails
    ... The Novell crap was originally run on IPX ... The term in the early-mid nineties was "packet storm". ... The original advantage of UDP was ... > 60 bytes for TCP. ...
    (alt.computer.security)
  • Re: A question regarding MTU: how it can effect TCP performance + other queries
    ... Can you check if your physical NIC has TCP large send offload enabled? ... I can't think of anything for the UDP case however, that just seems strange to me. ... Are you grouping multiple UDP packets in one TCP packet? ... encapsulated within another TCP packet when passed to physical interface, while for UDP I am sending UDP packet encapsulated within TCP packet when passed to physical interface. ...
    (microsoft.public.development.device.drivers)