Subject: [ipfix] IPFIX requirements - final changes

From: Juergen Quittek <[email-masked]>
Date: Thu, 22 May 2003 14:43:49 +0200

Dear all,

Addressing the comments received from IESG review, we are working
on a new - and hopefully final version of the requirements document.

For reference, you will find a complete list of issues and
their status at the end of this message.

Several comments could be addressed by editorial changes and
clarifications. They are already committed. But five comments
suggest changes on which I want to have WG consensus before
committing them. Please state if you see a problem with any
of the suggested changes listed below (or if you have a
better alternative).

  - More concrete definition of byte counter
      old text:
         "8. byte counter
             Which bytes of a packet are counted MUST be
             defined exactly."
      suggested replacement:
         "8. byte counter
             The sum of the total length of all IP packets
             belonging to the flow. The total length of a
             packet covers IP header and IP payload."

  - More concrete definition of multicast replication factor
      old text:
         "20. multicast replication factor
              the number of outgoing packets originating from
              a single incoming multicast packet. This is a
              dynamic property of multicast flows, that may
              change over time. For unicast flows it has the
              constant value 1. The computation of the factor
              MUST be clearly defined."
      suggestion: Replace last sentence by
             "The reported value MUST be the value of the
              factor at the time the flow record is exported."

  - More concrete definition of BGP-related attributes
      old text:
         "In addition, the exporting process MAY be able to
          report attributes related to inter-autonomous
          system routing of a flow, for example by reporting
          BGP Autonomous System numbers [RFC1771]."
      suggestion: replace text by three new MAY attributes
         "27. source BGP Autonomous System number [RFC1771]
          28. destination BGP Autonomous System number
          29. next hop BGP Autonomous System number"

  - Confidentiality from SHOULD to MUST
      suggestion: Change confidentiality requirement in
                  section 6.3.3 from SCHOULD to MUST.

  - Anonymization from MAY to MUST
      suggestion: Change anonymization requirement in
      section 6.7 from MAY to MUST.

Cheers,

    Juergen

Here is the complete list of changes:

==============================
IPFIX Requirements Open Issues
==============================

========================================================================
1. timestamp resolution reference
========================================================================
Problem Description:
------------------------------------------------------------------------
   5.4.  Timestamps

     The metering process MUST be able to generate timestamps for the
     first and the last observation of a packet of a flow at the
     observation point. The timestamp resolution MUST be at least the one
     of the sysUpTime [RFC1213], which is one centisecond.

I think I'd rather see a reference to RFC3418 instead of RFC1213.
We can do so by RFC-Editor note. May want to check with authors too.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace ref to RFC1213 by ref to RFC3418
========================================================================
Status: solution committed
========================================================================

========================================================================
2. reporting TOS/traffic class octet or reporting DSCP
========================================================================
Problem Description:
------------------------------------------------------------------------
On page 14 I see:

      9. type of service octet (in case of IPv4), traffic class
         octet (in case of IPv6)

Is that not better state as

      9. DSCP, which is set in the type of service octet (in case of IPv4),
         or in the traffic class octet (in case of IPv6)
========================================================================
Suggested solution:
------------------------------------------------------------------------
   According to RFC 2474, the DSCP covers only 6 bit of the type of
   service octet, and in some cases you want to see the entire byte.
   This is be pointed out by a comment added to item 9.:
   "According to RFC 2474 these octets include the DiffServ Code Point
   that has a length of 6 bit."
========================================================================
Status: solution committed
========================================================================

========================================================================
3. location of reference to RFC 2119
========================================================================
Problem Description:
------------------------------------------------------------------------
   I would prefer to see the paragraph referencing RFC 2119 in section 2.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   Move reference to RFC 2119 to section 2
========================================================================
Status: solution committed
========================================================================

========================================================================
4. bad wording in section 6.3.3, last paragraph
========================================================================
Problem Description:
------------------------------------------------------------------------
   Last paragraph in section 6.3.3 needs to be reworded.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace
     "The security threats from which these 3 requirements are deducted
      are explained in the "Security Considerations" (Section 10)."
   by
     "The security requirements have been derived from an analysis of
      potential security threads. The analysis is summarized in
      Section 10."
========================================================================
Status: solution committed
========================================================================

========================================================================
5. describe potential problem of faked DoS attack
========================================================================
Problem Description:
------------------------------------------------------------------------
   In section 10.2, an important point is left unsaid.  If the injection of
IPFIX traffic fool the network provided into thinking that a DOS attack is
underway, the countermeasures employed by the network provider may actually
deny service to real customers.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   no suggestion for a wording, yet
========================================================================
Status: solution required
========================================================================

========================================================================
6. location of appendix
========================================================================
Problem Description:
------------------------------------------------------------------------
   The appendix needs to be moved up in the document.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   move appendix above references, copyright, and authors' addresses
========================================================================
Status: solution to be committed
========================================================================

========================================================================
7. consistency of appendix
========================================================================
Problem Description:
------------------------------------------------------------------------
   The appendix is outdated. Alignment with the text sections and
   coverage of all requirements need to be checked and fixed.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   no suggestion, yet
========================================================================
Status: solution required
========================================================================

========================================================================
8. More concrete definition of byte counter
========================================================================
Problem Description:
------------------------------------------------------------------------
This document goes to a lot of trouble to say exactly what is
exported (e.g. what fields, etc), except for two cases:

      8. byte counter
         Which bytes of a packet are counted MUST be defined exactly.

This document is defining what fields are being reported on;
why can't it also define these two things that must also be
defined?  Is it useful to have different ipfix protocols exporting
different measurements?
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace "Which bytes of a packet are counted MUST be defined
   exactly." by "The sum of the total length of all IP packets
   belonging to the flow. The total length of a packet covers
   IP header and IP payload."
========================================================================
Status: solution to be agreed on
========================================================================

========================================================================
9. More concrete definition of multicast replication factor
========================================================================
Problem Description:
------------------------------------------------------------------------
This document goes to a lot of trouble to say exactly what is
exported (e.g. what fields, etc), except for two cases:

     20. multicast replication factor
         the number of outgoing packets originating from a single
         incoming multicast packet. This is a dynamic property of
         multicast flows, that may change over time. For unicast flows
         it has the constant value 1. The computation of the factor MUST
         be clearly defined.

This document is defining what fields are being reported on;
why can't it also define these two things that must also be
defined?  Is it useful to have different ipfix protocols exporting
different measurements?
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace last sentence by "The reported value MUST be the value of the
   factor at the time the flow record is exported."
========================================================================
Status: solution to be agreed on
========================================================================

========================================================================
10. More concrete definition of BGP-related attributes
========================================================================
Problem Description:
------------------------------------------------------------------------
Also, at the end of 6.1 it kind of says "Plus other stuff related to inter-AS
routing if you want".  It's already in the MAY section; can't they just
list some concrete items related to inter-AS routing as 27, 28, ...?
I don't think it's useful to say what amounts to "plus anything else that
you might feel like adding that you think is relevant", since that doesn't
encourage different people to make the same choices.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   add three more MAY attributes:
   - 27. source BGP Autonomous System number [RFC1771]
   - 28. destination BGP Autonomous System number
   - 29. next hop BGP Autonomous System number
========================================================================
Status: solution to be agreed on
========================================================================

========================================================================
11. Address the reliability issue of usage based accounting
========================================================================
Problem Description:
------------------------------------------------------------------------
The applications include usage-based accounting.  They should cite RFC 2975,
and indicate that the particular niche for usage-based accounting would not
be met if reliability was not very high.  Section 5.1 reliability requirements
do not meet the needs, nor do the timestamping of first and last packet of
a flow, because the flow may have been mischaracterized and that is first and
last of different flows.  The way to satisfy this issue is to caveat the
discussion of usage-based accounting with strong words on reliability that
counter the comments on lesser reliability and more probabilistic techniques
for other applications of ipfix.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   We need to state clearly, that many accounting applications require
   higher reliability than what is provided by the MANDATORY requirements.
   Where vwould be a good place to state this?
   Already in section 3.1?
   In section 6.3.2?
========================================================================
Status: solution required
========================================================================

========================================================================
12. Confidentiality from SHOULD to MUST
========================================================================
Problem Description:
------------------------------------------------------------------------
Requirements on the ipfix implementation - the document is long and I wonder if
the working group really meant the protocol's confidentiality and anonymization
features to be so optional -  SHOULD confidentiality, MAY anonymization.
Just for implementation.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   change confidentiality requirement in section 6.3.3
   from SCHOULD to MUST
========================================================================
Status: solution to be agreed on
========================================================================

========================================================================
13. Anonymization from MAY to MUST
========================================================================
Problem Description:
------------------------------------------------------------------------
Requirements on the ipfix implementation - the document is long and I wonder if
the working group really meant the protocol's confidentiality and anonymization
features to be so optional -  SHOULD confidentiality, MAY anonymization.
Just for implementation.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   change anonymization requirement in section 6.7 from MAY to MUST
========================================================================
Status: solution to be agreed on
========================================================================

--
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: Juergen Quittek <[email-masked]>
Date: Thu, 22 May 2003 17:00:34 +0200

Dear all,

I the message I posted earlier today there is an open issue that
does not need further discussion (at least I hope so) but some
concrete editing.

It concerns a statement on reliability. Since we had so many
controversal discussions on this issue, I ask on the list
for suggestions how to phrase this well.

If there is no response within a few days, I will write something by myself.

Please find below a description of this issue raised by the IESG reviewers.

    Juergen

---

From: Sebastian Zander <[email-masked]>
Date: Fri, 23 May 2003 03:26:51 +0200

Hi Juergen,

comments below

>             packet covers IP header and IP payload."

I just miss the word "bytes" in the definition:
The total length of an IP packet is the number of bytes in the
IP header and IP payload.

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
D-10589 Berlin, Germany                  www.fokus.fraunhofer.de/usr/sebastian.zander

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 23 May 2003 11:07:51 +0200

Sebastian,

> IP header and IP payload.

You are right!

What about

        "8. byte counter
            The sum of the total length in bytes of all IP
            packets belonging to the flow. The total length
            of a packet covers IP header and IP payload."

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Mon, 26 May 2003 17:01:51 +0200

Juergen,

>   from SHOULD to MUST

I'm just wondering if a MUST is not a little bit extreme.
The draft would become:
   "Confidentiality of flow specific data transferred from an exporting
   process to a collecting process MUST be ensured."
We all agree that over the Internet confidentiality is compulsory but 
this sentence would mean that even in a private LAN or environment, we 
must have confidentiality to be IPFIX compliant. And we know that, with 
the software based encryption, the throughput would be lowered. Ok, then 
we should have an crypto engine in hardware on the exporter to export 
the numerous flow export packets but there is a price to it.
My point is that, as Confidentiality is not needed in all cases, why 
make it a MUST?

Again, I have the same type of comments. Anonymization is not required 
in all cases. So why make it a MUST?

Regards, Benoit.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 26 May 2003 12:16:55 -0400

I agree that in a LAN confidentiality might not be an issue, although
anonymization might be.

Anyway, I agree with the MUST but we should append a "be able to" after it.
So a "IPfix Exporter MUST be able to provide confidentiality and
anonymization". This makes clear that will not be used all the time but it's
there if somebody needs it (beside being interoperable, etc, etc).

regards,

Reinaldo

---

From: "Tal Givoly" <[email-masked]>
Date: Mon, 26 May 2003 09:42:55 -0700

Juergen,

I agree with Benoit - it doesn't make sense to make confidentiality and
anonymization mandatory. In many deployments, there could be physical and
other security measures that addresses these issues.

Tal

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Benoit Claise
Sent: Monday, May 26, 2003 8:02 AM
To: Juergen Quittek
Cc: [email-masked]
Subject: Re: [ipfix] IPFIX requirements - final changes

Juergen,

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/

---

From: Alex Audu <[email-masked]>
Date: Tue, 27 May 2003 10:30:29 -0500

I support Reinaldo's comments on this issue. IPFix Exporter MUST support
confidentiality and anonymization. It is left for configuration to turn these on
as needed.

Regards,
Alex.

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 28 May 2003 10:06:39 +0200

Tal, Reinaldo, and Benoit,

Do we all have the following in mind?

   Anonymization and confidentiality MUST be covered by the
   protocol specification.  But the protocol specifiction
   specification defines it as a MAY feature (anonymization)
   or SHOULD feature (confidentiality) for IPFIX protocol
   implementations.

I guess this is what the IESG reviewers were referring to.

What is probably missing in the requirements document is a
statement like the following:

   Many requirements in this document are not explicitly
   stated as IPFIX protocol requirements, but as requirements
   for the metering process, the exporting process, or for
   other traffic measurement components. However, every
   requirement that needs support from the IPFIX protocol
   MUST be covered by the IPFIX protocol specification
   independent of the significance of the requirement,
   which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
   Note that the protocol specification itself also assigns
   significance attributes to its features, such that a
   protocol implementation does not necessarily need to
   implement all features.

Any comment on this?

    Juergen

---

From: Sebastian Zander <[email-masked]>
Date: Wed, 28 May 2003 12:18:58 +0200

Hi Juergen,

i think your second paragraph is a very good idea. But i don't
understand the last 2 sentences. My understanding is that the ipfix
requirement draft defines the ipfix protocol requirements. So i don't
understand why the protocol specification must cover all requirements.
E.g. when a requirementis optional why must it be covered in the protocol
specification?

I agree to say its a MUST for the protocol but not all exporters
and collectors must support it.

But i do *not* agree at all that in general anonymization and
confidentiality is not needed in a LAN. Anonymization can be required
in a LAN and even in a LAN confidentiality may be needed because i
don't want everybody who has access to my LAN to have access to my
IPFIX data.

Cheers,

Sebastian

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 28 May 2003 15:28:01 +0200

Sebastian,

> E.g. when a requirementis optional why must it be covered in the protocol

If the requirement doc says "the exporter MAY anonymize", then the
protocol specification MUST support anonymization in order to make
sure, that anonymization is interoperable. For example the protocol
spec MUST define how to inform a collecting process that the data it
receives is anonymized. Analogously, the protocol spec should specify
how to encrypt.

In both cases, the protocol specification can state that a concrete
implementation of the protocol MAY support features that serve
anonymization. Then an implementor can choose whether or not to implement
this OPTIONAL feature of the protocol.

> and collectors must support it.

Agreed.

> don't want everybody who has access to my LAN to have access to my

Also agreed.

Best wishes,

    Juergen

---

From: "Tal Givoly" <[email-masked]>
Date: Wed, 28 May 2003 08:11:38 -0700

Juergen,

I believe that what you described is definitely the way to go - extensions
that are fully specified to avoid ambiguity (a single well-defined way to
implement for interoperability), but not mandatory (either optional or
recommended).

In that case, should we also consider to fully specify the reliability
extensions in the same manner? how else would we assure that we comply with
the mandatory requirement that the protocol be extensible to support
reliability without providing at least a valid example, if not a complete
specification of a standard extension?

Tal

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: Wednesday, May 28, 2003 1:07 AM
To: Tal Givoly; Benoit Claise
Cc: [email-masked]
Subject: RE: [ipfix] IPFIX requirements - final changes

Any comment on this?

    Juergen

---

From: Sebastian Zander <[email-masked]>
Date: Thu, 29 May 2003 03:29:36 +0200

Juergen,

> this OPTIONAL feature of the protocol.

You are right. The req draft contains protocol specification requirements
(which is sometimes confusing and the reason why we get those comments).
But i suggest to change the middle sentence saying that all protocol
specification requirements from the req draft must be taken over into the
protocol draft *including their significance*. Otherwise why do we spend a
long time discussing the significance of some reqs if it is not used later
in the protocol draft? Furthermore some of the reqs may be targeting the
information model or achitecture draft instead of the protocol spec. So
the sentence should not only mention the protocol spec but *also the
information model etc*. (Jeff just gave an example that anonymization may
influence the information model.)

This statement must be put in the very beginning of the req draft.

The last sentence is not necessary in my opinion because its pretty obvious
that the protocol draft and the other drafts will use more (and more
detailed) reqs.

Then there is no need to change the requirements to MUST.

Cheers,

Sebastian

>> D-10589 Berlin, Germany                  
>> www.fokus.fraunhofer.de/usr/sebastian.zander
>>
>>
>>
>>
> 
> 
>

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 30 May 2003 14:50:10 +0200

Sebastian,

> influence the information model.)

I see your point, but I would suggest a different phrasing for the
following reason:
  - I do not expect that requirement items can be mapped one-to-one onto
    protocol features. Some individual protocol feature will cover several
    requirement items at once. So here you cannot map the significance
    one-to-one, but need something like a minimum significance to be
    considered.
  - My experience from designing other protocols is that - compared to the
    requirements - you usually increase significance of some features
    for technical or orther reasons. We must make sure that the protocol
    definition process has this level of freedom.

Therefore, I suggest to extend my initially suggested paragraph

 "Many requirements in this document are not explicitly
  implement all features."

by appending this sentence or a similar one:

 "However, the significance assigned to a protocol feature
  MUST NOT be lower than the significance of the corresponding
  requirements."

Cheers,

    Juergen