Subject: RE: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions)

From: "Carter Bullard" <[email-masked]>
Date: Tue, 3 Sep 2002 15:36:48 -0400

Gentle People,
   An unambiguous way of referring to the fragment most
likely to contain flow identifying information
is to refer to the "zero offset fragment".

   It is not correct to assume, however, that all the information
needed to track a standard 5-tuple flow is in the zero
offset fragment, as the algorithm allows fragmentation to
occur within the TCP header.  While there are RFC's that
suggest that this should not be allowed, some routers still
can fragment at the destination port field boundary.  I
believe that a paragraph that talks about fragmentation
should mention that some reassembly may be required.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street
Suite 18K
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax

> -----Original Message-----
> From: majordomo listserver 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, August 30, 2002 10:14 AM
> To: Benoit Claise
> Cc: Juergen Quittek; req
> Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX 
> Requirements Questions)
> 
> 
> Benoit Claise wrote:
> > 
> > Paul, Juergen and all,
> > 
> > >Benoit Claise wrote:
> > >
> > >
> > >>Paul and Juergen,
> > >>
> > >>
> > >>
> > >>>Hi Paul,
> > >>>
> > >>>--On 28 August 2002 09:06 -0400 [email-masked] wrote:
> > >>>
> > >>>
> > >>>
> > >>>>Juergen Quittek wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>>Hi Paul,
> > >>>>>
> > >>>>>--On 27 August 2002 20:26 -0400 [email-masked] wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>Juergen Quittek wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>>>--On 27 August 2002 14:49 -0400 
> [email-masked] wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>>As I work on the advocates document some questions 
> have come 
> > >>>>>>>>to mind on the requirements document.
> > >>>>>>>>
> > >>>>>>>>4.3 Distinguishing flows using Transport Header Fields
> > >>>>>>>>
> > >>>>>>>>      In the case of fragmented packets there are
> > >>>>>>>>      no port numbers. Are we saying flow state information
> > >>>>>>>>      MUST be maintained? In general, it is not clear from
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>No, the requirements document does not say so.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>>      the document what the requirements are for fragmented
> > >>>>>>>>      packets.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>I think the requirements should not include a 
> requirement for 
> > >>>>>>>keeping state of fragmented packets. Would you like 
> to see an 
> > >>>>>>>explicit statement on that? This would be a NO NEED FOR 
> > >>>>>>>statement :-)
> > >>>>>>>
> > >>>>>>>
> > >>>>>>      I think we need to be explicit. Most people will think
> > >>>>>>      of fragements as being counted in the same flow as the
> > >>>>>>      first packet not as 2 differernt flows.
> > >>>>>>
> > >>>>>>
> > >>>>>I see. Waht about adding a new subsection to Section 
> "5. Metering
> > >>>>>Process":
> > >>>>>
> > >>>>>5.8.  Packet Fragmentation
> > >>>>>
> > >>>>>   In case of IP packet fragmentation, only one 
> fragment of a single
> > >>>>>   packet might contain sufficient information for 
> classifying the
> > >>>>>   packet correctly. The metering process MAY keep state of
> > >>>>>   IP packet fragmentation in order to map fragments 
> that do not
> > >>>>>   contain sufficient header information correctly to flows.
> > >>>>>
> > >>>>>
> > >>>>  How about a slight re-wording...
> > >>>>
> > >>>>    In case of IP datagram fragmentation, only the 
> first fragment might
> > >>>>    contain sufficient information for classifying the 
> packet correctly.
> > >>>>    The metering process MAY keep state of IP 
> fragmentation in order to
> > >>>>    map fragments without sufficient header information 
> to the same
> > >>>>    flow as the first fragmented packet.
> > >>>>
> > >>>>
> > >>>Initially I also wanted to phrase like this. But it's IP. And 
> > >>>fragments might get re-ordered. The first fragment of a 
> packet that 
> > >>>is observed, is not necessarily the fragment containing 
> the TCP/UDP 
> > >>>header.
> > >>>
> > >>>Now, if you say "first", it is not clear whether you mean the 
> > >>>fragment with the first bytes of the IP payload or the first 
> > >>>fragment observed at the observation point. Your last sentence 
> > >>>seems to assume that the first observed packet is the 
> one with the 
> > >>>first bytes of the payload.
> > >>>
> > >>>
> > >>Why not merge your 2 texts:
> > >>
> > >>   In case of IP packet fragmentation, only one fragment 
> of the initial
> > >>   packet  might contain sufficient information for 
> classifying the
> > >>   packet correctly. Note that this fragment is the first 
> one generated
> > >>   by the router imposing the fragmentation, but might 
> not be the first
> > >>   one observed by the IPFIX device, due reordering reasons.
> > >>   The metering process MAY keep state of IP packet fragmentation
> > >>   in order to map fragments that do not contain sufficient header
> > >>   information correctly to flows.
> > >>
> > >>
> > >>
> > >
> > >       Juergen suggested a merged text. Are you suggesting
> > >       an alternative?
> > >
> > To summarize:
> > 
> > Juergen proposed:
> >   In case of IP datagram fragmentation, for many typical
> >   classification schemes, only one fragment contains
> >   sufficient information to classify the packet.
> 					   ^^^^^^
> 					   fragment
> 
> 	With the above change I think this is clear and easy to read. 
> 
> 
> > 
> > I proposed above:
> > 
> >    In case of IP packet fragmentation, only one fragment of 
> the initial
> >    packet  might contain sufficient information for classifying the
> >    packet correctly. Note that this fragment is the first 
> one generated
> >    by the router imposing the fragmentation, but might not 
> be the first
> >    one observed by the IPFIX device, due reordering reasons.
> >    The metering process MAY keep state of IP packet fragmentation
> >    in order to map fragments that do not contain sufficient header
> >    information correctly to flows.
> 
> 	This one is OK but goes into explanation I'm not sure 
> 	is necessary if you assume familiarity with IP. 
> 
> 	Also, there are 3 terms "initial packet", "packet"
> 	and "fragment". So I get a bit lost.
> 
> 	But either way will suffice as far as I'm concerned.
> 
> 
> > 
> > I think both of them express the same idea.
> > The second one maybe contains some more clarifications.
> > 
> > So I'm not really in favor of one or the other. Choose the one that 
> > you want to.
> > 
> > I'm not sure what were your conclusions for fragmentation 
> and section 
> > "6.1 Information Model"
> > 
> > 1. Have something like (implicitely talking about fragmentation):
> >       9. packet counter
> >          Which packets are counted MUST be defined exactly.
> >      10. byte counter
> >          Which bytes of a packet are counted MUST be 
> defined exactly.
> 
> 	Which bytes are counted is a legitimate issue. Do we include
> 	ethernet headers, IP headers, CRC, etc...In other words some
> 	bytes are never counted under ANY circumstances.
> 
> 	I don't see similar issues for the packet counter.
> 
> 	As soon as you start talking about which flow a packet gets
> 	counted against, it is a "Distinguishing Properties" issue.
> 	If you talk about what flows get counted it is a 
> 	configuration issue.
> 
> 	The question on fragment is are they distinguished by the
> 	full header information or just a subset. 
> 
> > 
> > OR
> > 
> > 2.
> >      9. packet counter
> >          Which packets are counted MUST be defined exactly.
> >      10. byte counter
> >          Which bytes of a packet are counted MUST be 
> defined exactly. 
> > And an extra sentence about fragmentation. "The behavior of 
> the byte 
> > and packet counters in case of IP packet fragmentation MUST 
> be clearly 
> > defined."
> > 
> > Regards, Benoit.
> > 
> > >
> > >
> > >
> > >>>
> > >>>
> > >>>>> [...]
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>>>6.1 information Model
> > >>>>>>>>
> > >>>>>>>>      9  Packet Counter
> > >>>>>>>>      10 Byte counter
> > >>>>>>>>
> > >>>>>>>>              As mentioned earlier, for fragments this
> > >>>>>>>>              requires state information? If there is no
> > >>>>>>>>              state info, then what flow are the counted
> > >>>>>>>>              towards?
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>Do you suggest to include a requirement for keeping fragment
> > >>>>>>>
> > >>>>>>>
> > >>>>>state info?
> > >>>>>
> > >>>>>
> > >>>>>>      A MAY is as far as I would go. There may 
> certainly be probes
> > >>>>>>      that have this capability. We should have a 
> requirement that
> > >>>>>>      says fragment counting MUST be clearly defined.
> > >>>>>>
> > >>>>>>
> > >>>>>OK. Currently, we have
> > >>>>>
> > >>>>>      9. packet counter
> > >>>>>         If a packet is fragmented, each fragment is 
> counted as an
> > >>>>>         individual packet.
> > >>>>>     10. byte counter
> > >>>>>         Which bytes of a packet are counted MUST be defined 
> > >>>>> exactly.
> > >>>>>
> > >>>>>What about appending
> > >>>>>
> > >>>>>         The behavior of the byte counter in case of IP packet
> > >>>>>         fragmentation MUST be clearly defined.
> > >>>>>
> > >>>>>
> > >>>>    With the new section on fragmentation I think we can
> > >>>>    eliminate any mention of it on the counters.
> > >>>>
> > >>>>
> > >>>The new section of the fragmentation is a MAY 
> requirement. But for 
> > >>>understamding the behavior of the byte counter you MUST know 
> > >>>whether or not the option is implemented.
> > >>>
> > >>>
> > >>So, haven't we enough with "The behavior of the byte and packet 
> > >>counters in case of IP packet  fragmentation MUST be clearly 
> > >>defined."?  We need the packet counter in the sentence above: to 
> > >>know if the flow state information is maintained for fragemented 
> > >>packets
> > >>
> > >>
> > >>
> > >>>
> > >>>
> > >>>>>?
> > >>>>>
> > >>>>>Please note that we also have in the MAY attributes section
> > >>>>>
> > >>>>>     26. fragmented packet counter
> > >>>>>         counter of all packets for which the 
> fragmented bit is set in
> > >>>>>         the IP header
> > >>>>>
> > >>>>>
> > >>>>    I'm not sure why this was added. If you want that info,
> > >>>>    make the IP fragment bit part of the flow definition.
> > >>>>
> > >>>>
> > >>It makes sense.
> > >>
> > >>Regards, Benoit
> > >>
> > >>
> > >>
> > >>>Do you suggest to remove it? Anyone else?
> > >>>
> > >>>
> > >>>    Juergen
> > >>>
> > >>>
> > >>>
> > >>>--
> > >>>Help        mailto:[email-masked] and say "help" in
> > >>>message body
> > >>>Unsubscribe mailto:[email-masked] and say 
> "unsubscribe 
> > >>>ipfix" in message body
> > >>>Archive     http://ipfix.doit.wisc.edu/archive/
> > >>>
> > >>>
> 
> --
> Help        mailto:[email-masked] and say "help" 
> in message body
> Unsubscribe mailto:[email-masked] and say 
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/