[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Status of Operational issues with Tiny Fragments in IPv6



These issues are already discussed in sections 2.1.10 and 2.1.11 of draft-v6ops-security-overview-04.

I didn't get involved too much in the discussion of Vishwas' draft because I had already been round the loop of suggesting to the ipv6 wg that the base standard should be modified to recommend
- no overlapping fragments and
- non-last fragments to be close to the guaranteed minimum MTU.

This didn't get much traction.  However the concerns are valid.

I would suggest that rather than making this into a separate draft we can look at improving the text in the security overview (if necessary) given that we are probably ging to have to do *another* round on this one.

Regards,
Elwyn

Vishwas Manral wrote:
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?
>