Subject: [ipfix] iesg comment on draft-ietf-ipfix-reqs-09.txt

From: Randy Bush <[email-masked]>
Date: Thu, 3 Apr 2003 09:01:34 -0800

comments from iesg reviewers

randy

---

I see:
   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.

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)

---

   I would prefer to see the paragraph referencing RFC 2119 in section 2.

   Last paragraph in section 6.3.3 needs to be reworded.

   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.

   The appendix needs to be moved up in the document.

---

Overall, I like it.  A couple of things jumped out at me, though.
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.

     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?

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.

---

This is a good document overall.

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.

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.

-30-

--
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: Fri, 04 Apr 2003 18:07:23 +0200

Hi all,

I think we got many good comments. Most of them can be committed quickly.
However, there are some that might require some discussion:

  - Does the Appendix need to be moved up in the document?
  - Shall we be more clear on byte counter, multicast replication factor,
    and BGP AS#s?
  - Do we agree that we need to add a statement on that accounting requirements
    can only be met with higher reliability?

I would answer 'no' on all three questions.  Please see some more detailed
statement on the comments below.

    Juergen
-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

> We can do so by RFC-Editor note. May want to check with authors too.

Certainly we should follow this suggestion.

>          or in the traffic class octet (in case of IPv6)

We discussed this before: 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.

>    I would prefer to see the paragraph referencing RFC 2119 in section 2.

Makes sense.

>    Last paragraph in section 6.3.3 needs to be reworded.

Let's try to find another wording.

> deny service to real customers.

Good point. We should discuss this threat also in some additional text.

>    The appendix needs to be moved up in the document.

Can anybody explain why?

> defined?  Is it useful to have different ipfix protocols exporting

This is a requirements document.  It is a preparation for defining
a single IPFIX standard protocol. Therefore, I do not see a problem in
leaving some (potentially tricky) issues to be defined by the protocol.

Also, this list was intended to name and briefly explain the attributes.
For the multicast replication factor, a definition takes several more words:
It is a dynamic property. What would be its value, if during the time since
the last report there were five outgoing packets per incoming packet and
just before the report was made, one receiver disconnected?
Would still 4 be correct for this report? Should it be 4.96? Or 5?
We has this discussion and found no requirement to prefer one or the other.

> encourage different people to make the same choices.

Well, the statement was not THAT general.  When discussing the BGP issues, we
found that source AS#, destination AS#, previous hop AS#, and next hop AS# could
be useful. Shall we list all of them as 27, 28, 29, 30?

> for other applications of ipfix.

Citing RFC 2975 is fine.

But the WG could not agree on a statement, that this niche would not be met
if reliability was not very high. We found non-neglectible counter-examples.

I think there will be consensus on a statement like "Some accounting applications
require high reliability".

> features to be so optional -  SHOULD confidentiality, MAY anonymization.

Sorry, what is the proposal here?

    Juergen

---

From: Randy Bush <[email-masked]>
Date: Fri, 4 Apr 2003 13:01:57 -0800

> We discussed this before: 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.

it is not clear that saying this would damage the document

>>    The appendix needs to be moved up in the document.

because appendices are more comfortable above references, copyright,
and authors' addresses?

> This is a requirements document.  It is a preparation for
> defining a single IPFIX standard protocol. Therefore, I do not
> see a problem in leaving some (potentially tricky) issues to be
> defined by the protocol.

is there a danger in making very clear that all measurements of the same
phenomonon should produce the same result?

> Also, this list was intended to name and briefly explain the
> attributes.  For the multicast replication factor, a definition
> takes several more words: It is a dynamic property. What would be
> its value, if during the time since the last report there were
> five outgoing packets per incoming packet and just before the
> report was made, one receiver disconnected?  Would still 4 be
> correct for this report? Should it be 4.96? Or 5?  We has this
> discussion and found no requirement to prefer one or the other.

any harm in stating this?

> I think there will be consensus on a statement like "Some
> accounting applications require high reliability".

i think our not making this more loudly and clearly explicit early
on led us down enough ratholes already.  so i would suggest making
it quite clear that real accounting would require more than ipfix
is promising to provide.

>> 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.

maybe make confidentiality and anonymization mandatory to implement
but not mandatory to use?

randy

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 07 Apr 2003 04:40:00 +0200

> it is not clear that saying this would damage the document

Should not be a problem to minimize damage when clarifying this.

> because appendices are more comfortable above references, copyright,

Thanks. Moving it up will be easy.

> phenomonon should produce the same result?

No, not at all.  But the reviewer requested to solve open questions
(specify attribute semantics more clearly).  This takes time and
would delay this document again.  Also, there is the info & data
model document, which has exactly the goal of specifying attributes
in more detail.

> any harm in stating this?

No. But it would also perfectly fit in the info & data model document.

> it quite clear that real accounting would require more than ipfix

Fine.  Let's be more explicit.

> but not mandatory to use?

This would be a significant change. Most of the other requests of the
reviewers concern clarifications or editorial changes, but this
one addresses the requirements itself.

We should exchange pro and con arguments on stricter requirements for
confidentiality and anonymization on the list.