Subject: [ipfix] Re: IESG comments on: draft-ietf-ipfix-reqs-13.txt

From: Juergen Quittek <[email-masked]>
Date: Fri, 16 Jan 2004 23:30:21 +0100

Bert,

Inline please find replies on all COMMENTs and DISCUSSes.  I hope they
are sufficient for a discussion at the next IESG phone conference.

All of them are covered by the new version -14 that I just submitted
to the I-D repository.  If you need a preview before it appears on
the I-D server, please find the document at

<ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-14.txt>

Thanks,

    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

--On 09.01.2004 16:12 Uhr +0100 Wijnen, Bert (Bert) wrote:

> The IESG discussed your document on our bi-weekly telechat
> yesterday. The results are below. You can also see them
> in the ID-tracker.
>
> In general, a DISCUSS statement needs to be fixed or we need to
> give a proper answer/explanation why what we have is OK.
>
> A COMMENT statement describes things that IESG memebers noticed
> while reviewing and could be improved. So if we do a change to
> address the DISCUSSes (from Margaret and Russ), then we might
> as well try to address as much COMMENTs as we can.
>
> I hope we can do a quick revision and do not need another
> 6-8 months since the last time it appeared on the IESG
> agenda.
>
> Thanks,
> Bert
> -------------- IESG DISCUSSes and COMMENTs ---------
> Steve Bellovin:
> Comment:
> 4.2(4) doesn't parse.
>
> Ned Freed:
> Comment:
> Nit: No IPR boilerplate

added IPR notices.

> Security considerations section here is IMO very nice.
>
> Ted Hardie:
> Comment:
> Minor comment: I think it would be useful to move section 4.6 up, so that the note
> relating to encrypted header fields occurs before the requirements which cannot be met for
> encrypted header fields

Moved encryption section from number 4.6 to number 4.1.

> Russ Housley:
> Discuss:
> My comments from 2003-04-03 were addressed, but one of themin a confusing
> way.  I believe that these comments are pretty minor.  Hopefully they
> can be addressed much more quickly than the previous ones.
>
>   In section 6.3.3, the difference between 'specific data' and 'IPFIX
>   data' is not clear to me.

6.3.3 does not just talk about 'specific data', but of 'flow specific data'
when confidentiality is addressed.  When integrity and authenticity is addressed,
section 6.3.3 talks about IPFIX data.  The phrasing was not chosen well.
The intention was to address 'flow-related data'.  The reasoning behind it
was that confidentiality is definitely required for the flow-related data
transferred using IPFIX.  Confidentiality is much less necessary for the data
describing the configuration of the metering process.  That's why we left this
out when requiring confidentiality.

But now I see, there might also be reasons to protect confidentiality of
metering process configuration information.  And since it is also less confusing
this way, I replaced 'flow-specific data with 'IPFIX data'.  Now 'IPFIX data
is consistently used for all security requirements in section 6.3.3.

>   In section 12, the large table includes this row:
>
>     | Sect. |    Requirement          |  A  |  B  |  C  |  D  |  E  | IPFIX|
>     |-------+-------------------------+-----+-----+-----+-----+-----+------|
>     | 6.3.3.| Confidentiality        |  M  |  S  |  S  |  S  |  S  |  M  |
>     |-------+-------------------------+-----+-----+-----+-----+-----+------|
>
>   I believe that the discussion in section 10 indicates that column D
>   ought to contain 'M' instead of 'S'.

Fixed.

> Comment:
>   I find the structure of section 4.2 very awkward.  There has to be a
>   better way to say the same thing.  Also, there are no MAY requirements
>   in the list that follows the introductory sentence.

replaced

  "The metering process MUST, SHOULD, or MAY be able to separate flows
   by the following fields of the IP header as indicated.

      1. source IP address (MUST)

      2. destination IP address (MUST)

      3. protocol type (TCP,UDP,ICMP,...) (MUST)

      4. IP version number (SHOULD)
         This requirement only applies if the observation point is
         located at a device that is supporting more than IP version.

   For source address and destination address, separating by full match
   MUST be supported as well as separation by prefix match."

by

  "The metering process MUST, SHOULD, or MAY be able to separate flows
   by the following fields of the IP header as indicated.

      1. source IP address

      2. destination IP address

      3. protocol type (TCP, UDP, ICMP, ...)

   For source address and destination address, separating by full match
   MUST be supported as well as separation by prefix match.

   The metering process SHOULD be able to separate flows by the IP
   version number if the observation point is located at a device that
   is supporting more than IP version."

>   In section 4.6, the document acknowledges that some header fields may
>   not be available if encryption is used.  I think the placement of this
>   text would be better in the introduction to section 4.  the resulting
>   section would say: unless the use of security protocol that provides
>   encryption prevents the gathering of of the following information, then
>   the solution MUST ....

Ted Hardie's alternative suggestion was applied: 4.6 was moved up to became 4.1.

>   In section 10.1: s/spy out/spy on/

fixed.

> Allison Mankin:
> Comment:
> The  -13 revision has addressed the concerns on anonymization, congestion avoidance and retransmission I expressed about earlier drafts, all of which were passed on to the ipfix mailing list.
>
> Margaret Wasserman:
> Discuss:
> I have included my specific comments on this document below.  In
> general, I think it is a reasonable document, but I have a couple
> of concerns that I think should be addressed before publication:
>
> (1) I don't understand the section that discusses the significance
>     of how the terms MUST, SHOULD or MAY are used in this document.

replaced confusing 'MANDATORY' by 'REQUIRED' in section 1, paragraph 3
and section 3, paragraph 3.  I hope this addresses the comment, but
I am not sure.

> (2) The list of information that an exporting process must be
>     able to report in section 6.1 includes several items that
>     may not be constant for a given flow, given the definition
>     of "flow" in this document, so it isn't clear how they can
>     be reported for all flows.

The introduction of section 6.1 explains that the exporting process
MUST SHOULD or MAY be >>able<< to report the listed flow attributes,
not that they are necessarily constant for each flow.  Certainly,
they it does not make sense to report them if they are not constant
for a certain flow.  But (as the introduction of section 6.1 says)
which attributes are to be reported depends on the configuration of
the exporting process.

> More details and a few editorial comments are included below:
>
>   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 and related
>   standard documents independent of the significance of the
>   requirement, which can be MANDATORY (MUST), RECOMMENDED (SHOULD), or
>   OPTIONAL (MAY).
>
>>> This doesn't make any sense to me.  If these are the requirements
>>> for a protocol, then what does it mean to say that a requirement
>>> is OPTIONAL (MAY)?  That it MUST be supported by the protocol?

It means that it MUST be included in the protocol specification as
an OPTIONAL feature.

> 4.2.  IP Header Fields
>
>   The metering process MUST, SHOULD, or MAY be able to separate flows
>   by the following fields of the IP header as indicated.
>
>>> Editorial comment:  There are no "MAYs" in the list.

Fixed, see above.

>       1. source IP address (MUST)
>
>       2. destination IP address (MUST)
>
>       3. protocol type (TCP,UDP,ICMP,...) (MUST)
>
>       4. IP version number (SHOULD)
>         This requirement only applies if the observation point is
>         located at a device that is supporting more than IP version.
>
>   For source address and destination address, separating by full match
>   MUST be supported as well as separation by prefix match.
>
>>> Shouldn't you be able to identify a flow based on the IPv6
>>> Flow ID?

This requirement was discussed some time ago.  The outcome was that
we did not find a relevant usage scenario that would have justified
such a requirement.

> 4.5.  DiffServ Code Point
>
>   If the observation point is located at a device supporting
>   Differentiated Services (DiffServ) then the metering process MUST be
>   able to separate flows by the DiffServ Code Point (DSCP, see
>   [RFC2474]).
>
>>> Why isn't this listed as an IP header field?  And why do you
>>> want to be able to identify flows based on the DSCP, but not
>>> the full traffic class?

Again, we found relevant scenarios where distinguishing by
DSCP was considered important enough for having this requirement.
We did not find relevant scenarios that required including the
remaining bits of the traffic class octet.  That was also the
reason why it was not listed as header field. Please note that
not having a requirement does not exclude implementing it.

>   The exporting process MUST be able to report the following attributes
>   for each metered flow:
>
>       1. IP version number
>         This requirement only applies if the observation point is
>         located at a device supporting more than one version of IP.
>
>>> How is a device that requests flow information supposed to know
>>> whether or not the observation point supports more than one
>>> version of IP?

Not necessarily by means of IPFIX.  Note that the requirement is
about being >>able<< to distinguish flows by the IP version.  This
does not imply that this distinction is applied if it is not requested
by the device requesting flow information.

>       2. source IP address
>       3. destination IP address
>       4. IP protocol type (TCP,UDP,ICMP,...)
>       5. if protocol type is TCP or UDP: source TCP/UDP port number
>       6. if protocol type is TCP or UDP: destination TCP/UDP port number
>       7. packet counter
>         If a packet is fragmented, each fragment is counted as an
>         individual packet.
>       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.
>       9. type of service octet (in case of IPv4), traffic class
>         octet (in case of IPv6).  According to RFC 2474 these octets
>         include the DiffServ Code Point that has a length of 6 bits.
>     10. in case of IPv6: Flow Label
>     11. if MPLS is supported at the observation point: the top MPLS
>         label or the corresponding forwarding equivalence class (FEC,
>         [RFC3031]) bound to that label.  The FEC is typically defined
>         by an IP prefix.
>     12. timestamp of the first packet of the flow
>     13. timestamp of the last packet of the flow
>     14. if sampling is used: sampling configuration
>     15. unique identifier of the observation point
>     16. unique identifier of the exporting process
>
>>> Is it assumed that these values will be constant for any
>>> captured flow?  This isn't consistent with the definition
>>> of "flow" used in this document.  As an example, if a flow
>>> is defined as all traffic between two IP addresses, the
>>> items 4, 5, 6, 9, 10 and 11 may not be constant.

Not at all.  Some may be constant, some may be not.  The packet
counter is usually not constant.  The requirement is about the
ability of the exporting process to report these (constant or
non-constant) attributes.  Whether or not it is useful to report
an attribute or not depends on the flow to be measured.  Which
attribute is to be reported depends on the exporting process'
configuration.  This requirement just says that it MUST/SHOULD/MAY
be possible to configure that the listed attributes are exported.

> 10.  Security Considerations
>
>   An IPFIX protocol must be capable to transport data over the public
>
>>> Editorial: s/capable to transport/capable of transporting

fixed.

>   Internet.  Therefore it cannot be excluded that an attacker captures
>   or modifies packets or inserts additional packets.
>

--
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: Sat, 17 Jan 2004 23:11:05 +0100

Bert,

I forgot to address Steve's comment explicitly, but I guess it was covered.
Please see the comment inline.

Thanks,

    Juergen

> <ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-14.txt>

I do not really understand what Steve means, but I hope it is
addressed by the modification of Secton 4.2, see below.

[...]