Subject: Comments on draft-manral-v6ops-tiny-fragments-issues-02.txt

From: Suresh Krishnan <[email-masked]>
Date: Tue, 06 Jun 2006 13:09:00 -0400

Hi Vishwas,
   I read this draft and acknowledge that the problem described in the 
draft is very real. I had looked at this issue before and I could not 
arrive at a reasonable solution. I will talk about each of the 4 
presented solutions

a. Impose a minimum packet size for the non-last fragments. If a
    fragment of a lesser size is received, the packet is treated as a
    malformed packet and is discarded.

This is the most feasible solution but it is not very effective. Let's 
say we arrive at a minimum non-last fragment size X (<1280 of course). 
It is very possible to make fragments of 1280 octets without containing 
the ULP header by filling it with useless hop by hop options and 
extension headers.

b. Reassemble all the fragments of the packet, translate the header
    fields and, glean out relevent information and then pass the original
    fragments ahead after modifying the relevent fields.

c. Reassemble all the fragments of the packet till we have the header
    fields of the upper layer , glean out relevent information and then
    pass the original fragments ahead after modifying the relevent
    fields.

b and c will lead to denial of service attacks since an attacker can 
send enough fragments which DO NOT contain the upper layer protocol port 
and make the node wait for the last one, thus exhausting memory on the 
assembling node.

d. If upper layer protocol present then the header must be there in
    the first fragment.

The difficult question is what to do if the ULP layer is NOT present in 
the first fragment (Drop or Permit?)

Thanks
Suresh

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Jun 2006 11:15:30 -0700

Vishwas:

I have gotten some comments off-list, and some comments on.

The general consensus of what I'm hearing is that the draft is  
incomplete, but hits on a real problem, which is that of overlapping  
fragments resulting in a variety of attack. Your primary concern is  
not that, however, it is the matter of the first fragment managing to  
enable a firewall to mis-apply a rule, allowing a packet to get  
through because the port number is in the second fragment.

The security overview document draft-ietf-v6ops-security- 
overview-04.txt, in sections 2.1.10 and 2.1.11, addresses  
fragmentation-related issues. The IESG has bounced that back with a  
number of comments, and so there will need to be a new draft posted.  
I would suggest that you correspond with the authors, copied; I  
believe that you will find that they are willing to make sure your  
issues are covered in that draft.

Fred

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 6 Jun 2006 23:47:56 +0530

Hi Suresh,

Thanks for the review of the document. I will add further comments for
each of the options described.

I agree with most of the points, however option b. and c.. provide the
best solution for most cases as reordered fragments etc can also be
treated correctly(to prevent memory exhaustion, we wait for reassembly
for only a particular configurable short period of time, besides
having a limit on the number of such framents we will assemble at any
one time). Besides that I think for option d. we should deny the
packet and will add that to the next version of the draft. Do let me
know iif you disagree?

Another issue I would like to add to the draft is, that raised by Jim
Bound about what to do with unrecognized extension headers in middle
boxes . I will also add the option of dropping overlapping fragments
as mentioned by Elwyn and Stig quite a few times in the working group.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 6 Jun 2006 23:50:12 +0530

Forgot to mention, I am evaluating the need to to add an option E to
the draft the Joeroen mentioned, though I think it is the same as
option C, mentioned in the draft.

Thanks,
Vishwas