[R2.21-Build 95]: vrouter fragments handling issues and limitations

Bug #1493687 reported by alok kumar
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R2.20
Won't Fix
Low
Raja Sivaramakrishnan
R3.0
Won't Fix
Low
Raja Sivaramakrishnan
R3.2
Won't Fix
High
Raja Sivaramakrishnan
R4.0
Won't Fix
High
Raja Sivaramakrishnan
Trunk
New
High
Raja Sivaramakrishnan

Bug Description

Listing few issues which was found during out of order fragments testing:

1. Fragments with partial TCP header gets dropped but still creates the flow and next fragments gets forwarded to receiver.In this case as first fragment would be missing, receiver can not reassemble it which will cause retransmission.

2. Overlapping fragments:
        When the fragment head has full TCP header and next fragments offset is 1 then vrouter forwards this fragment.This may cause problem when fragments with offset 1 overwrites the flags fields of TCP header.

To avoid issues 1 and 2, as per RFC 1858:

"A general algorithm, then, for ensuring that filters work in the
      face of both the tiny fragment attack and the overlapping fragment
      attack is:

         IF FO=1 and PROTOCOL=TCP then
                 DROP PACKET
"

3. limitation of flow buffer size 3. sometime this leads to fragments loss when fragment head is received after 3 or more fragments.
If fragments received in order f1,f2,f3,f4,f0 then f3 and f4 may get dropped.

As per discussion with Raja:
[9/2/15, 11:02:21 AM] Raja Sivaramakrishnan: If the flow was already present when the fragments are received in this order, vrouter will forward f0, f1, f2, f3, f4.
[9/2/15, 11:04:51 AM] Raja Sivaramakrishnan: If this is the first packet of the flow, then timing comes into play. If agent sets f0 to forward before vrouter gets around to processing f0 (asynchronously), no drops will occur. Otherwise, f0, f1, f2 will be forwarded. f3, f4 will be dropped (but the flow will continue to remain, so if the retransmission is also similarly fragmented, we should be ok).
[9/2/15, 11:07:48 AM] Raja Sivaramakrishnan: I am about to go offline now. Anything else to discuss?
[9/2/15, 11:09:25 AM] alok kumar: but we storing all the fragments till flow is created?
[9/2/15, 11:11:48 AM] alok kumar: if there is separate fragment buffer to store all the frags then why we need to drop few. this part im not able to understand.
[9/2/15, 11:14:23 AM] Raja Sivaramakrishnan: yes, but the flow entry itself has space for only 3 packets. It is possible to forward the other fragments, but will take more work. Don’t think it can be done in 2.21.

4. Mixed fragments with same id for same source/destination/proto tuple: in this case fragments may go to wrong receiver(diff. ports).This is mostly limitation for this case as vrouter does not have any information which fragment belongs to which packet if ID is same.

alok kumar (kalok)
summary: - [R2.21-Build 95]: vrouter fragments handling issues
+ [R2.21-Build 95]: vrouter fragments handling issues and limitations
tags: added: releasenote
chhandak (chhandak)
information type: Proprietary → Public
Changed in juniperopenstack:
assignee: nobody → Raja Sivaramakrishnan (raja-u)
status: New → Won't Fix
Revision history for this message
Jun Wei Wang (wjw7869) wrote :

I used contrail R3.0 version now and found that if fragment happened in UDP packet, the performance dropped distinctly. Is it related to this bug?

Thanks
Andy Wang

Jim Reilly (jpreilly)
information type: Public → Private
tags: added: att-aic-contrail
Jim Reilly (jpreilly)
tags: added: blocker
Jim Reilly (jpreilly)
information type: Private → Public
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.