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?
>> >
>>
>