Status of Operational issues with Tiny Fragments in IPv6

["Vishwas Manral" <vishwas.ietf@gmail.com>]

Hi Fred,

Thanks a lot for summarizing the issue. I have changed the subject
line to more closely reflect the discussion. Just to remind the people
the discussion on this topic happened more on the ipv6 list than on
the v6ops list.
The way I see the problem is that we have middlebox devices, so that
we do not have to cram all the functionality in each of the end
devices and it also makes the entire thing easier to manage.

A lot of basic attacks(example SYN flood) are detected by seeing
discrepancies in the header fields. For IPv4 firewalls will drop/ send
to slow path packets with IP options and the packet of below 64 bytes
is dropped for non-last fragment. In IPv4 this way we solve the
problem of having the header fields not broken across fragments.

In IPv6 options are now a standard part.of the protocol. We need to
state what the non-last fragment size can be because by doing so we do
not have a way for the attacker to pass the firewall yet be accepted
by an end host.
A simple solution recommended by the IPv6 chairs was to drop all such packets.

Thanks,
Vishwas
On 5/26/06, Fred Baker <fred@cisco.com> wrote:
> OK, folks. Lets get a review.
>
>    http://www.ietf.org/internet-drafts/draft-manral-v6ops-tiny-
> fragments-issues-02.txt
>   "Operational issues with Tiny Fragments in IPv6", Vishwas Manral,
> 9-Jan-06,
>   <draft-manral-v6ops-tiny-fragments-issues-02.txt>
>
> The principal comment that I noted from our previous discussion was
> that the problem existed for IPv4 also, and hence was not
> specifically an IPv6 problem. The working group did not choose to
> make a recommendation on the topic, and personally I wasn't aware
> that we were asked to. The key recommendation seems to be that there
> be a minimum MTU size large enough to contain the IPv6 header (with
> all of its additional headers) plus the second layer header, and that
> middleware devices like firewalls discard messages that were a non-
> last fragment and were smaller than that size.
>
> In such a case, this would convert the attack to another kind of
> attack, one in which the target is bombarded with fragments of
> messages, but never enabled to reassemble them, and attacking the
> reassembly tables and associated memory. The solution for that is
> fortunately trivial - in the event that there is any any overload in
> this area, discard the oldest fragment in the buffer and any other
> fragments that are presumptively part of the same message - the same
> way we protect TCP TCBs.
>
> The origin of the discussion was in Mobile IP, where related issues
> were addressed.
>
> What do folks wish the document said? Is this something for the
> working group to make an effort on? Is there a feeling that it should
> be a working group draft?
>
>
> On May 24, 2006, at 11:56 PM, Vishwas Manral wrote:
>
> > Hi Fred,
> >
> > I thought it was an important enough issue to be addressed, from
> > the operational perspective.
> >
> > If possible I would want to drive it further. Would be eager to get
> > your views on the same.
> >
> > Thanks for restarting the discussion,
> > Vishwas
> >
> > On 5/24/06, Fred Baker <fred@cisco.com> wrote:
> > On May 24, 2006, at 12:02 AM, Vishwas Manral wrote:
> >
> > > I am not sure the draft http://www.ietf.org/internet-drafts/draft-
> > > manral-v6ops-tiny-fragments-issues-02.txt is dead. It still exists
> > > in the IETF repository.
> >
> > Yes, it is in the repository; it remains until they flush it out.
> > What I was saying is that discussion seems to be at an end.
> >
> > What would you like to do with it further? Do you plan to continue
> > driving this?
> >