On Fri, 25 Nov 2005, Stig Venaas wrote:
On Fri, Nov 25, 2005 at 03:14:11AM -0800, Vishwas Manral wrote:
Hi Brian,
Though there are no requirements as you said about TCP header being
seen, we know of issues that have happened in IPv4. By leaving the same
in IPv6 we could very easily be inviting further simpler attacks.
By not seeing the TCP field, the level of granularity considerably
reduces for "firewalling" and other application level tweaks that are
now done over the internet.
Right. So on the receiving end it's tempting to simply discard a packet
if fragments overlap. However, at least in theory, a genuine packet
could be sent with overlapping fragments since not forbidden.
Or should I simply assume that it must be some kind of attack if they
overlap? No sane operating system would send overlapping fragments...
I prefer the later approach: overlapping fragments are non valids.
I know this is draconian, but we should not repeat problems of IPv4.
Regards,
Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98
Stig
Is there a reason we should not specify such a limit? Backward
compatibility, etc?
Thanks,
Vishwas
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brian E Carpenter
Sent: Friday, November 25, 2005 4:25 PM
To: Stig Venaas
Cc: [email protected]
Subject: Re: IPv6 and Tiny Fragments
Stig Venaas wrote:
On Fri, Nov 25, 2005 at 12:53:37AM -0800, Vishwas Manral wrote:
Hi Janos,
I think that is the minimum Link MTU and not the smallest size
non-last
fragment.
Can you point me to the RFC/ draft which says what you stated?
Yes, I believe that is the minimum link MTU. So, obviously one
fragment
might be smaller. I haven't seen anything say which fragment
(reasonable
that it is the last, but haven't seen anything saying it must be), and
nothing prohibiting leaving several fragments smaller.
>
Also, there is sadly nothing saying overlapping fragments are not
allowed.
I suppose people writing code are assumed to exercise common sense,
e.g. make the first fragment as large as possible and don't overlap
fragments. But neither is required to make reassembly work. (Nor
is in-order reception of fragments required.)
It isn't a requirement in the Internet that intermediate systems can
see the transport header, so none of this seems to me to be a bug
in RFC 2460. The Unfragmentable Part definition there seems correct
to me.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
