RE: Status of Operational issues with Tiny Fragments in IPv6

["Bound, Jim" <Jim.Bound@hp.com>]

Hi Vishwas,

My first question was if the issue is not doing complete packet
reassembly and as I see that issue it simply is a requirement for any
node receiving an end-to-end set of fragments the way it is done with
IPv6.  Once the packet is assembled and processed then this next issue
requires analysis, but the next header values can assist with locating
upper layer headers but RFC 2460 is pretty clear on receivers:

From RFC 2460:

Therefore, extension headers must
   be processed strictly in the order they appear in the packet; a
   receiver must not, for example, scan through a packet looking for a
   particular kind of extension header and process that header prior to
   processing all preceding ones.

A firewall or intrusion detection need to make certain implementation
decisions as they are typically not the end receiver per RFC 2460.  The
question really is when an extension header does not apply to the
implementation it can by pass that extension?

But from RFC 2460:

If, as a result of processing a header, a node is required to proceed
   to the next header but the Next Header value in the current header is
   unrecognized by the node, it should discard the packet and send an
   ICMP Parameter Problem message to the source of the packet, with an
   ICMP Code value of 1 ("unrecognized Next Header type encountered")
   and the ICMP Pointer field containing the offset of the unrecognized
   value within the original packet.  The same action should be taken if
   a node encounters a Next Header value of zero in any header other
   than an IPv6 header.

So I view the issue possibly not one of tiny fragments as all because
nodes need to do packet assembly, but how do secure interim nodes
process ext headers before the next header these secure interim nodes
require.

My answer is as follows.  The node IP stack implementation must adhere
to the spec.  But, the IETF makes no requirement at all what users
implement or any other standards body, as all we really provide is the
opportunity and ability for things to work correctly from our
specifications. Firewalls or edge Intrusion Detection
devices/software/sensors are anomaly's within the users environment to
protect them beyond what open networking standards define.  Thus, in
this case of implementations that want to do next header scan as for a
Firewall it is certainly possible and in my humble "individual" (not HP)
opinion valid code path, or as you stated fast-path. 

End result is not clear. There is an issue but lets see what other v6ops
persons think as again maybe I am just missing the forest for the trees,
but it is not the IETF or any standards bodies business to mandate use
to the market that is their prerogative to accept or alter anything we
provide them from the IETF.

Hope this helps,
/jim


 

> -----Original Message-----
> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] 
> Sent: Tuesday, May 30, 2006 1:06 AM
> To: Bound, Jim
> Cc: Fred Baker; Templin, Fred L; Elwyn Davies; v6ops@ops.ietf.org
> Subject: 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
> >
>