hi all, I have a capture of trying to connect to a RSA Server. I see the first UDP packet from client to RSA Server and I see a packet coming from the RSA Server back. Than i see 4 packets (each sent 5 seconds after the previous one) and each being 550 bytes. I came accross : http://www.cisco.com/c/en/us/support/docs/security-vpn/secureid-sdi/116304-technote-rsa-00.html#anc6 *"A typical SDI exchange involves four packets, each of which is 550 bytes, but that might change with the RSA server version"* The capture was taken at the client. Since this is UDP i cannot tell what happened to this 4 packets. My question - if I capture the traffic on both sides , should I be able to find the same 4 UDP packets in the capture from the RSA Server ? I found some information (older posts , not sure if it's still valid) that some Firewalls were not processing UPD packets > 512 bytes ? Is this still true? BR Adam asked 25 Sep '15, 12:42  adasko |
One Answer:
Yes
No, only 'ancient' firewall will block anything based on size. Of course you can configure some firewalls to block frames based on size, but that's rather silly. Regards answered 26 Sep '15, 15:35  Kurt Knochner ♦ showing 5 of 10 show 5 more comments |
Thank you Kurt for answering my questions.
How would I "look" for the packets on the RSA Server ? Since this is a UDP conversation not SEQ numbers are used. Would I have to filter for the socket pair combination (what if NAT is in play ? ) would be the only option be to search after the size of the packets?
what about a TCP conversation ? I know that Wireshark is using the ISN as relative zero. will I be able to track packets based on the real sequence number (after I disable relative sequence numbers in protocol preferences ?) on the opposite host ?
Thank you in advance. Best Regards
Adam
Yes.
Then it gets more complicated. You could look at the IP ID, some NAT devices don't touch that field. The timestamp should also help to narrow down things. Further than that, there are not much options left to compare frames, except the payload of the frames.
Yes, but some security devices (firewall) change the SEQ as well, so that's not a reliable criteria.
Regards
Kurt
Thank you, very informative! So basically, for both UDP and TCP it's better to compare the payload of the frame,correct ? Also what I would like to ask,is it possible for a packet/frame to be changed in size due to passing via a intermediary device say Firewall etc? What I mean, when we configure span on a virtual VMware switch and define the bytes to be reported to say 64 bytes I will end up with frames recorded in wireshark not bigger as 64 bytes.
Thank you and best regards Adam
Yes and no ;-) YES, it is possible, if the intermediary device has a bug and thus changes things it should not change. And NO, this should not happen.
I'm not sure what that actually means ("and define the bytes to be reported to say 64 bytes"), but it sounds like you limited the number of bytes that were captured/recorded. If so, it would be the same as the '-s' option of tcpdump/Wireshark. It means, you only captured the first 64 Bytes of every frame, even if the frame was larger!
I see. You wrote about the IP identification field, that I could use it. I was assuming that this field is used for fragmentation and reasamble only. Why would a NAT device change it? I mean, I understand that depending on the NAT option used it will change the IP or IP & port number, but it will modify the packet or will the device performing NAT actually create a new packet to send it out? Did you mean that this can trigger the IP ID field to be changed? You also mentioned that some security devices like Firewalls may change the sequence number. I'm just wondering, if it does change it, can the conversation still be considered reliable? I mean let's host A is at seq nbr 101 and is sending 1500 bytes to host B. If a say Firewall in between will modify the seq to 111 how can both keep track on what was sent and what was acknowledged ?
Best Regards Adam
@adasko: You are right with the need of the IP ID. But in fact nearly every device is setting this field, if needed or not. You can read some facts about the IP ID here: http://crnetpackets.com/2015/08/29/a-short-story-about-the-ip-id-field/
well, how would you define "create a new packet". A router allways "creates" a new packet, by copying the contents of the old frame and by creating a new one, just with different MAC addresses, so ...
yes, but not because of the "new" packet, because the IP ID gets changed on purpose (IP ID randomization) to prevent passive OS fingerprinting or similar reasons.
If that device does it in the right way, yes ;-)
A (SEQ: 1000 + 500) ---> Firewall (SEQ: 9000 +500) ---> B (SEQ: 9000 + xx)
B only sees what the Firewall sent, it's like a "TCP proxy".
Please excuse for the late replay – I had to do some reading and take time to sum it up in my head. Could you please just confirm with YES / NO (or please add additional comments to correct myself) the following:
a)The IP ID field was originally meant (still is) for fragmentation and reassembly purposes.
b)When a router will have to process the data to a network with lower MTU it will perform fragmentation. So, if the original packet has the IP ID set to 0x61ca after fragmentation ALL packets that originated from the original packet will have the same value inside the Identification field (to identify fragments of the original packet).
c)Each packet must have a unique IP ID for the given conversation.
d)If I would connect two hosts via a crossover cable (no device in-between) the IP ID value for each single packet sent from A to B would be identical in both trace files.
e)If there is any device between A and B that will change the IP ID value, I cannot really use this field on the receiving end to find packets sent from A.
f)The IP ID randomization as Kurt mentioned is for security reasons to prevent for example passive OS fingerprinting.
g)I took a look on a trace file (captured few of them) , narrowed down to onestream / conversation and I can see that each time the “first” IP ID value is always different but some sites mentioned that normally the value increments by 1 for each packet. In my example I have a trace file of a connection between 2 MS hosts and in fact I can see that the IP ID value for host A is incrementing by 1 for each packet BUT the fifth packet is incremented by 1841 … I tried to google this but without luck. Could this be perhaps also a “way” of this randomization, I mean that there is no really a clear pattern on how this IP ID filed is incremented.
[EDIT] Found this "Newer operating systems, such as the recent Linux kernel, OpenBSD, and Windows Vista, randomize the IP ID, but older operating systems and hardware (such as printers) typically do not."
So the IP ID is generated by the host but if older did not use randomization does that mean that each packet was ALWAYS incremented by 1 o?
h)Also when devices performing NAT, Firewalls do change the IP ID they do it not because of a bug or miss behavior , it’s done by them for security reasons (IP ID randomization to prevent passive OS spoofing).
I really appreciate your time and expertise. I learn something new with each and every post!
Best Regards
Adam
a.) - e.): yes (more or less)
f.) Is this a question or a statement?
g.) + EDIT: correct
h.) yes
@adasko for g) it could be that you different concurrent sessions between this hoast. Remember that the IP ID must be unique for non atomic datagrams for the 3 tupels of (IP SRC, IP DST and L4 protocol Type). But a lot of stacks do not care in there generation of IP ID if the datagram is atomic or not.
So even a IP ID of 0x0 would be correct for a atomic datagramm.
o Atomic datagrams: (DF==1)&&(MF==0)&&(frag_offset==0)