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

From: Juergen Quittek <[email-masked]>
Date: Wed, 28 Aug 2002 18:31:52 +0200

... and here's my reply to Paul's second forwarded message.

    Juergen

---------- Forwarded Message ----------
Date: 28 August 2002 18:17 +0200
From: Juergen Quittek <[email-masked]>
To: [email-masked]
Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements    Questions)

Paul,

--On 28 August 2002 11:40 -0400 [email-masked] wrote:

> Juergen Quittek wrote:
>>
>> Hi Paul:
>>
>> --On 28 August 2002 10:36 -0400 [email-masked] wrote:
>>
>> > Juergen Quittek wrote:
>> >>
>> >> 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.
>> >
>> >       GOod point. How about this...
>> >
>> >
>> >      In case of IP datagram fragmentation, only one fragment contains
>> >      sufficient information to fully classify the packet. The metering
>> >      process MAY keep state of IP fragmentation in order to
>> >      map fragments without sufficient header information to the same
>> >      flow as the fully classified fragmented packet.
>> >
>>
>> Fine, with one exception:
>>
>>      In case of IP datagram fragmentation, _it might be that_ only
>>      one fragment contains sufficient ...
>>
>> If you just classify by IP addresses, fragmentation is not a problem.
>
> 	Yeah, I thought of that caveat. But so as not to loose
> 	the main idea I chose "fully classify". I agree it pushes
> 	the caveat to the background. However, I think if the
> 	main idea is understood, the caveat becomes clear.
>
> 	what about this...
> 		In case of IP datagram fragmentation and depending
> 		on the classificaiton scheme, only one fragment contains
> 		sufficient information to classify the packet.

Sounds much better. However, if you say "depending on ...", I would
rather use "might contain" instead of "contains".

What about

   In case of IP datagram fragmentation, for many typical
   classification schemes, only one fragment contains
   sufficient information to classify the packet.

       Juergen
>
>>
>> >
>> >
>> >>
>> >> >>  [...]
>> >> >>
>> >> >> >> > 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.
>> >
>> >       I assumed the clearly defined byte counter meant whether
>> >         or not you include the ethernet header, the IP header,
>> >       the CRC, etc...
>> >
>> >       The counters will count bytes and packets that map to
>> >       the same flow. It doesn't matter if it is a fragment or not.
>> >       So I see this as a flow mapping issue only, not a counter issue.
>>
>> Now, I see. Agreed.
>>
>> >>
>> >> >> ?
>> >> >>
>> >> >> 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.
>> >>
>> >> Do you suggest to remove it? Anyone else?
>> >
>> >       Yes. I suggest we remove it.
>>
>> Fine with me.
>>
>>      Juergen

---------- End Forwarded Message ----------

Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions)
From: Juergen Quittek <[email-masked]>
To: [email-masked]
Date: Wed, 28 Aug 2002 18:17:58 +0200

Paul,

--On 28 August 2002 11:40 -0400 [email-masked] wrote:

> Juergen Quittek wrote:
>>
>> Hi Paul:
>>
>> --On 28 August 2002 10:36 -0400 [email-masked] wrote:
>>
>> > Juergen Quittek wrote:
>> >>
>> >> 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.
>> >
>> >       GOod point. How about this...
>> >
>> >
>> >      In case of IP datagram fragmentation, only one fragment contains
>> >      sufficient information to fully classify the packet. The metering
>> >      process MAY keep state of IP fragmentation in order to
>> >      map fragments without sufficient header information to the same
>> >      flow as the fully classified fragmented packet.
>> >
>>
>> Fine, with one exception:
>>
>>      In case of IP datagram fragmentation, _it might be that_ only
>>      one fragment contains sufficient ...
>>
>> If you just classify by IP addresses, fragmentation is not a problem.
>
> 	Yeah, I thought of that caveat. But so as not to loose
> 	the main idea I chose "fully classify". I agree it pushes
> 	the caveat to the background. However, I think if the
> 	main idea is understood, the caveat becomes clear.
>
> 	what about this...
> 		In case of IP datagram fragmentation and depending
> 		on the classificaiton scheme, only one fragment contains
> 		sufficient information to classify the packet.

Sounds much better. However, if you say "depending on ...", I would
rather use "might contain" instead of "contains".

What about

   In case of IP datagram fragmentation, for many typical
   classification schemes, only one fragment contains
   sufficient information to classify the packet.

       Juergen
>
>>
>> >
>> >
>> >>
>> >> >>  [...]
>> >> >>
>> >> >> >> > 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.
>> >
>> >       I assumed the clearly defined byte counter meant whether
>> >         or not you include the ethernet header, the IP header,
>> >       the CRC, etc...
>> >
>> >       The counters will count bytes and packets that map to
>> >       the same flow. It doesn't matter if it is a fragment or not.
>> >       So I see this as a flow mapping issue only, not a counter issue.
>>
>> Now, I see. Agreed.
>>
>> >>
>> >> >> ?
>> >> >>
>> >> >> 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.
>> >>
>> >> Do you suggest to remove it? Anyone else?
>> >
>> >       Yes. I suggest we remove it.
>>
>> Fine with me.
>>
>>      Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 28 Aug 2002 18:30:57 +0200

Here is my reply to Paul's first message.

---------- Forwarded Message ----------
Date: 28 August 2002 16:49 +0200
From: Juergen Quittek <[email-masked]>
To: [email-masked]
Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements   Questions)

Hi Paul:

Now, I see. Agreed.

Fine with me.

     Juergen

---------- End Forwarded Message ----------

Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions)
From: Juergen Quittek <[email-masked]>
To: [email-masked]
Date: Wed, 28 Aug 2002 16:49:32 +0200

Hi Paul:

Now, I see. Agreed.

Fine with me.

     Juergen