[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of Operational issues with Tiny Fragments in IPv6
Hi Jim,
You raise a valid concern.
The issue I see in my view came up when working on firewalls in the
Fastpath. I figured out that in IPv4 the header options are optional,
so packets with options are either sent to the slow path or are
dropped(the more common case). This also means that a non-last
fragment of less than 64 bytes can easily be dropped(which means that
we will have the TCP header in the first fragmet), so most TCP and
transport level header checks like TCP-SYN attacks can be easily
detected. Even a simple 5 tuple based check may not work.
In IPv6, however the extension headers are part of the base protocol
and as we do not have a minimum length for non-last fragment, there is
no way to guarantee that the TCP header is present in the first
header. So basic checks as above cannot be done easily.
That said, for IPsec ESP tunnelled packets(for AH the header inside
can always be looked into) the IPsec authentication at the device
doing the decryption will guarantee that the packet is valid. Note
with RFC4301 the authentication itself is a MUST for ESP now.
Do let me know if I am missing the point altogather?
Thanks,
Vishwas
On 5/29/06, Bound, Jim <Jim.Bound@hp.com> wrote:
I may be missing the issue in the draft but I take the main issue to be
as follows:
From section 4 of the spec
>Having tiny fragments could mean that none of the fragments would be
the Initial
>Fragment. So any access control/ tunneling based onthat may not work
unless reassembly >is done, or extra state like nextHeader and previous
header length remaining are kept >across fragments.
My first thought now is this is life with IPv4 or IPv6. Packet assembly
and reassembly is required. The spec does not provide for me why this
cannot be done from an IETF protocol view for IPv6.
Is this an implementation problem and not IETF specification problem,
thus it was correct to send it to v6ops to do logic check if there is
anything we can do operationally to address the stated issue.
I don't think this spec should even move forward, but again maybe I am
missing the issue that is other than the mid box doing normal packet
reassembly for IPv6?
NB: Also if the packet was encrypted with IPsec many of the security
issues are addressed and also the entire notion of Firewalls for
implementation (as opposed to IETF standardization) is current
discussion in multiple market vertical segments how end-to-end with
IPsec is implemented when Firewalls are present.
Best,
/jim