Subject: Re: [ipfix] new element: fragmentOffsetIPv6 ?

From: Juergen Quittek <[email-masked]>
Date: Mon, 08 May 2006 03:07:08 +0200

Dear all,

It's OK, if you want to have this new IE.
Please help me to specify it correctly.

RFC 2460 defines for the IPv6 fragment extension header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fragment Offset      13-bit unsigned integer.  The offset, in 8-octet
                        units, of the data following this header,
                        relative to the start of the Fragmentable Part
                        of the original packet.

   Res                  2-bit reserved field.  Initialized to zero for
                        transmission; ignored on reception.

   M flag               1 = more fragments; 0 = last fragment.

If we define a fragment offset IE for IPv6,
we probably should also define the a fragment flag IE for IPv6.
Below is a suggestion for their definitions.  Comments are welcome.

5.3.29.  fragmentOffsetIPv6

   Description:
      The value of the IPv6 fragment offset field in the IPv6 fragment
      extension header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 211
   Status: current
   Reference:
      See RFC 2460 [RFC2460] for the specification of the fragment
      offset in the IPv6 fragment extension header.

5.3.30.  fragmentFlagIPv6

   Description:
      The value of the M flag in the IPv6 fragment extension header.

         Bit  0:    M flag.
         Bits 1-7: (DC) Don't Care, value is irrelevant.

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           |   | D | D | D | D | D | D | D |
           | M | C | C | C | C | C | C | C |
           +---+---+---+---+---+---+---+---+

   Abstract Data Type: octet
   Data Type Semantics: flags
   ElementId: 212
   Status: current
   Reference:
      See RFC 2460 [RFC2460] for the specification of the M flag in the
      IPv6 fragment extension header.

Thanks,

    Juergen

--On 21.04.2006 15:08 Uhr +0200 Benoit Claise wrote:
>
> Lutz, Paul,
>>
>>> We have #88 = fragmentOffsetIPv4 - but no equivalent for IPv6
>>> fragment offset?
>>>
>>> See section 4.5 of RFC 2460.
>>>
>>> I suggest we allocate #211 for this.
> Since this is a gap in the I.E. list, this makes sense!
>>>
>>>
>>> BTW, there are also no elements to report Hop-by-Hop Options (section
>>> 4.3) or Destination Options (section 4.6).
>>>
>>
>> for IPv4 this elem is part of the IPv4 header while
>> in IPv6 there is a special extension header for
>> the fragment data. So maybe this should be made
>> clear by the IE name.
>>
>> eg. IPv6ExtHdrFragmentOffset
> Agreed.
>
> Regards, Benoit.
>>
>>
>> --
>> 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/

---

From: Paul Aitken <[email-masked]>
Date: Mon, 08 May 2006 13:28:54 +0100

Juergen,

> It's OK, if you want to have this new IE.

Fragment offset is AF agnostic, so why create a new IE? Why not fix #88 
fragmentOffsetIPv4 to just be "fragmentOffset" ?

The cisco definition of this field is "The fragment-offset value from 
fragmented IP packets", so our intention was clearly for AF independence.

> RFC 2460 defines for the IPv6 fragment extension header:

Do you propose to include the Res and M flags in the FO IE definition? 
If so, that makes it incompatible with the IPv4 FO in two ways:

1. The IPv4 flags (R, DF, MF) come immediately before the FO, not after

2. The IPv4 FO IE doesn't contain any flags.

So let's not do that. Let's have #88 as a generic FO value, where the 
first three bits are reserved and must be zero:

	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Res |      Fragment Offset    |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>      offset in the IPv6 fragment extension header.

I propose to combine it with #88.

>         Bits 1-7: (DC) Don't Care, value is irrelevant.

It might be easier to encode this as

              0   1   2   3   4   5   6   7
            |   |   |   |   |   |   |   | M |

For two reasons:

1. No need to shift the M bit around. Just mask it from the packet contents.

2. In future the two Res bits can easily be fitted in positions 5+6 if 
their use is defined.

So I would prefer to call it fragmentFlagsIPv6 (ie, plural, akin to 
fragmentFlagsIPv4), and specify it as:

              0   1   2   3   4   5   6   7
            |   |   |   |   |   | 0 | 0 | M |

BTW, I would prefer to specify that zero be used instead of DC to 
prevent a potential covert channel.

Cheers.
-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 08 May 2006 16:09:29 +0200

Hi Paul,

--On 08.05.2006 13:28 Uhr +0100 Paul Aitken wrote:

> Fragment offset is AF agnostic, so why create a new IE?
> Why not fix #88 fragmentOffsetIPv4 to just be "fragmentOffset" ?

Well that would also be fine with me.

I'm just a bit surprised, because it was you who suggested a new IE #211
for reporting the IPv6 fragment offset:

> IPFIXers,
>
> We have #88 = fragmentOffsetIPv4 - but no equivalent for IPv6 fragment offset?
>

Does this means that you withdraw your original proposal?

> If so, that makes it incompatible with the IPv4 FO in two ways:

Certainly not.  I just put the IPv6 fragment header specification here
in order to show what we are talking about.

> So let's not do that. Let's have #88 as a generic FO value, where the first three bits are reserved and must be zero:
>

That's also fine with me.  I will suggest a new description
and reference section for this IE.

But then there is still the issue with the fragment flags.
For IPv4 we have them in IE #197.

We do have the following:

5.3.28.  fragmentFlagsIPv4

   Description:
      The value of the fragmentation bits in the IPv4 packet header.

         Bit 0:    reserved, must be zero.
         Bit 1:    (DF) 0 = May Fragment,  1 = Don't Fragment.
         Bit 2:    (MF) 0 = Last Fragment, 1 = More Fragments.
         Bits 3-7: (DC) Don't Care, value is irrelevant.

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           |   | D | M | D | D | D | D | D |
           | 0 | F | F | C | C | C | C | C |
           +---+---+---+---+---+---+---+---+

   ElementId: 197

Shall we extend this also to IPv6.  This would be simple:
In the IPv6 fragment header there is no equivalent to the DF flag.
So this bit would always be 0.  But there is an equivalent to the
MF flag that is called M flag.  Thus, we can report the M flag as
value of Bit 2.

Any problems with this solution?

> 2. In future the two Res bits can easily be fitted in positions 5+6 if their use is defined.
>
> So I would prefer to call it fragmentFlagsIPv6 (ie, plural, akin to fragmentFlagsIPv4), and specify it as:
>
>               0   1   2   3   4   5   6   7
> BTW, I would prefer to specify that zero be used instead of DC to prevent a potential covert channel.

If we go for joint offset reporting, I would apply the same idea here
and use IE #197 for IPv4 and IPv6 as suggested above.

Thanks,

    Juergen

---

From: Paul Aitken <[email-masked]>
Date: Mon, 08 May 2006 15:28:30 +0100

Juergen,

> Does this means that you withdraw your original proposal?

Later I sent another message where I proposed combining the two, because 
I realised that there's no need for AF-dependant versions.

Perhaps you didn't receive that message?

>         Bits 3-7: (DC) Don't Care, value is irrelevant.

Other than that it requires shifting the IPv6 bits around, no.

You  may suppose to reserve bits 0 and 1 for the IPv6 Res bits, so the 
IPv6 definition should be:

              0   1   2   3   4   5   6   7
            +---+---+---+---+---+---+---+---+
            |   |   | M | D | D | D | D | D |
            | 0 | 0 | F | C | C | C | C | C |
            +---+---+---+---+---+---+---+---+

> and use IE #197 for IPv4 and IPv6 as suggested above.

It seems a good solution.

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 08 May 2006 22:29:11 +0200

Hi Paul,

--On 08.05.2006 15:28 Uhr +0100 Paul Aitken wrote:

> Later I sent another message where I proposed combining the two,
> because I realised that there's no need for AF-dependant versions.
>

No.  And I cannot find it in the IPFIX mailing list archive.
But that's not an issue.  I am fine with your new proposal.

> You  may suppose to reserve bits 0 and 1 for the IPv6 Res bits, so the IPv6 definition should be:

I don't think we can reserve bit 1.  We can only use the IE for v4 and v6 if the
semantics is the same in both cases.  Otherwise we run into trouble if a receiver
of the IE does not know the IP version that was observed.

So, the semantics of each bit should be identical for both versions:

5.3.28.  fragmentFlags

   Description:
      Fragmentation properties indicated by flags in the IPv4
      packet header or the IPv6 Fragment header, respectively.

         Bit 0:    (RS) Reserved.
                   The value of this bit MUST be 0 until specified
                   otherwise.
         Bit 1:    (DF) 0 = May Fragment,  1 = Don't Fragment.
                   Corresponds to the value of the DF flag in the
                   IPv4 header.  Will always be 0 for IPv6 unless
                   a "don't fragment" feature is introduced to IPv6.
         Bit 2:    (MF) 0 = Last Fragment, 1 = More Fragments.
                   Corresponds to the MF flag in the IPv4 header
                   or to the M flag in the IPv6 Fragment header,
                   respectively.  The value is 0 for IPv6 if there
                   is not Fragment header.
         Bits 3-7: (DC) Don't Care.
                   The values of these bits are irrelevant.

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           | R | D | M | D | D | D | D | D |
           | S | F | F | C | C | C | C | C |
           +---+---+---+---+---+---+---+---+

Best regards,

    Juergen

---

From: Paul Aitken <[email-masked]>
Date: Mon, 08 May 2006 22:00:43 +0100

Juergen,

> No.  And I cannot find it in the IPFIX mailing list archive.

So I re-sent it privately.

> of the IE does not know the IP version that was observed.

True. But then it's possible to export the IP version if a receiver 
might need to know it.

>                   respectively.  The value is 0 for IPv6 if there

"is no".

>                   The values of these bits are irrelevant.

Thanks.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 09 May 2006 00:00:30 +0200

Paul,

Do you think we can play the game also with IE #54
identificationIPv4?

We would rename it to fragmentIdentification and
apply it to v4 and v6 as well.

We would have to extend its size to unsigned32,
but this should not create a severe incompatibility with
NFv9. NFv9 reports containing IE #54 would still be valid.

Any comment?

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 08 May 2006 23:34:59 +0200

Paul,

Thanks for proofreading the text.  I'll fix it.

Would it be fine with you to re-use IE #211 for the
commonPropertiesId?

Thanks,

    Juergen

--On 08.05.2006 22:00 Uhr +0100 Paul Aitken wrote:

> True. But then it's possible to export the IP version if a receiver might need to know it.
>
>

---

From: Paul Aitken <[email-masked]>
Date: Tue, 09 May 2006 12:21:36 +0100

Juergen,

> Would it be fine with you to re-use IE #211 for the

Yes.

---

From: Carter Bullard <[email-masked]>
Date: Tue, 9 May 2006 08:59:58 -0400

Please, lets not talk about covert channels in IPFIX.  It isn't a  
part of
any real threat assessment for IPFIX, and IPFIX doesn't meet any
potential covert channel criteria.   In this particular case, because
some of the contents of this IE is under the control of a non-trusted
source (the packet), controlling other parts of the data in this field
provides no additional assurance or protection, against a covert
channel.

Some would say that MBZ fields in IPFIX IE's is analogous to 7-bit
data (ASCII) enforcement to eliminate the covert channel potential
of FTP.

Carter

On May 8, 2006, at 8:28 AM, Paul Aitken wrote:

> Fragment offset is AF agnostic, so why create a new IE? Why not fix  
> #88 fragmentOffsetIPv4 to just be "fragmentOffset" ?
>
[ snip ]

---

From: Paul Aitken <[email-masked]>
Date: Tue, 09 May 2006 15:12:40 +0100

Juergen,

> NFv9. NFv9 reports containing IE #54 would still be valid.

The cisco definition of this field is currently IPv4 specific - but I 
think it'd be good to extend it to IPv6 as you describe.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 9 May 2006 10:58:08 -0400

All,

Since TOS and Traffic Class are registered identically for IPv4 and  
IPv6 (RFC 2474,  http://www.iana.org/assignments/dscp-registry; RFC  
3168, http://www.iana.org/assignments/ipv4-tos-byte),  
classOfServiceIPv4 and classOfServiceIPv6 would also seem to be  
subject to the same reassignment (classOfServiceIPv4 =>  
classOfService; classOfServiceIPv6 => available).

Regards,

Brian

On May 9, 2006, at 10:12 AM, Paul Aitken wrote:

> The cisco definition of this field is currently IPv4 specific - but  
> I think it'd be good to extend it to IPv6 as you describe.
>
> -- 
> Paul Aitken

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 10 May 2006 21:50:15 +0200

Hi Carter,

--On 09.05.2006 8:59 Uhr -0400 Carter Bullard wrote:

> Please, lets not talk about covert channels in IPFIX.  It isn't a  part of
> potential covert channel criteria.

I doubt that IPFIX does not even meet a single potential covert channel criteria.
The protocol security considerations discuss features for protecting integrity.
For example, transport over TLS is supported.

> In this particular case, because

"Some would say ..."  that's fine.  But what do YOU want to tell us?
Are you suggesting not to request to set some of the unused bits to zero?
Do you suggest to remove this from all affected IEs or from some
particular ones?

Thanks,

    Juergen

>> # 88 fragmentOffsetIPv4 to just be "fragmentOffset" ?
>>
> [ snip ]
>>

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 28 May 2006 23:52:03 +0200

Hi Paul,

--On 09.05.2006 15:12 Uhr +0100 Paul Aitken wrote:

> The cisco definition of this field is currently IPv4 specific -
> but I think it'd be good to extend it to IPv6 as you describe.

Done:

5.3.26.  fragmentIdentification

   Description:
      The value of the Identification field in the IPv4 packet header or
      the IPv6 Fragment header, respectively.  The value is 0 for IPv6
      if there is no Fragment header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 54
   Status: current
   Reference: See RFC 791 [RFC0791] for the definition of the IPv4
      Identification field.  See RFC 2460 [RFC2460] for the definition
      of the Identification field in the IPv6 Fragment header.

5.3.27.  fragmentOffset

   Description:
      The value of the IP fragment offset field in the IPv4 packet
      header or the IPv6 Fragment header, respectively.  The value is 0
      for IPv6 if there is no Fragment header.
   Abstract Data Type: unsigned16
   Data Type Semantics: identifier
   ElementId: 88
   Status: current
   Reference:
      See RFC 791 [RFC0791] for the specification of the fragment offset
      in the IPv4 header.  See RFC 2460 [RFC2460] for the specification
      of the fragment offset in the IPv6 Fragment header.

5.3.28.  fragmentFlags

   Description:
      Fragmentation properties indicated by flags in the IPv4 packet
      header or the IPv6 Fragment header, respectively.

         Bit 0:    (RS) Reserved.
                   is no Fragment header.

             0   1   2   3   4   5   6   7

   Abstract Data Type: octet
   Data Type Semantics: flags
   ElementId: 197
   Status: current
   Reference:
      See RFC 791 [RFC0791] for the specification of the IPv4 fragment
      flags.  See RFC 2460 [RFC2460] for the specification of the IPv6
      Fragment header.

---

From: Carter Bullard <[email-masked]>
Date: Tue, 30 May 2006 09:21:07 -0400

Juergen,
I was commenting on Paul's desire to "avoid a convert channel".
I just didn't want the WG to get the wrong impression about IPFIX
and covert channel avoidance, and making a statement seemed
appropriate.   I apologize if I was in error.

I suggest that bits that are not used be defined as 'reserved'.  The  
IETF
should have guidelines on the appropriate value for reserved fields,
but if they don't,  then the worry about reserved fields should be moot.
I would suggest that in the absence of IETF guidelines, you mention
that any reader should be able to process an IE that has arbitrary  
values
in the reserved field, as is good practice.  Writers of IE's should zero
reserved fields, but there is no requirement to do so.

The reason you don't want to specify MBZ is backward compatibility
for future versions of the protocol which actually try to use the  
reserved
bits.   If the standard states that the field 'must be zero', then an  
IPFIX reader
should throw away data if the reserved bits are set to something other
than zero.   That seems like the correct response to be conformant with
the standard.   But when we go to version 1.1 and the reserved bit has
real semantics, then how does a 1.0 transport entity know that its ok to
forward the the 1.1 data?   Because there are many IE's and thus many
reserved fields, just keeping up with which version of the protocol  
allows
for the use of this bit, for each specific IE can become somewhat  
burdensome.

So, I suggest, "reserved" but not MBZ.

Carter

>>> fragmentFlagsIPv4), and specify it as:

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

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

---

From: Paul Aitken <[email-masked]>
Date: Tue, 30 May 2006 19:16:17 +0100

Carter wrote:

> [snip]

> So, I suggest, "reserved" but not MBZ.

And I agree.

Thanks.