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
On 6/6/06, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
> 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
>
>