[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-manral-v6ops-tiny-fragments-issues-02.txt
- To: "Suresh Krishnan" <suresh.krishnan@ericsson.com>
- Subject: Re: Comments on draft-manral-v6ops-tiny-fragments-issues-02.txt
- From: "Vishwas Manral" <vishwas.ietf@gmail.com>
- Date: Tue, 6 Jun 2006 23:47:56 +0530
- Cc: v6ops@ops.ietf.org
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IRBbQmbsGnOLcWxG7L+2hXVFNjcVYCxXX9M+KNLvaqIOI9OZd2sCcVN/bGRXQWWaC7pOLpASrwN9I1khKzA3s2ic4Pk7tT1WCliDYnRaPN+H9oKYDIHKoxteZULocKakse7XhuW9bc3gmXl/0KuLlaa1kPKnHOwjEUk6Qe986sY=
- In-reply-to: <4485B6AC.1040709@ericsson.com>
- References: <4485B6AC.1040709@ericsson.com>
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