Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators
draft-ietf-ipfix-mediation-protocol-10

[Ballot discuss]

RFC5892, section 8 says that a measurement system "must
also prevent" a bunch of attacks, which are listed in
bullets. This draft seems to provide mechanisms that could
allow that to happen.  But I'm not sure - are all those
threats handled really?  In particular, what "prevents" a
bogus MITM here?  And where is there a statement that a
strong confidentiality mechanism MUST be implementd or
used?

Sorry I ran out of time to check properly, and it could be
that this is spec'd in RFC 6183 and/or 7011. The secdir
review implies that its fine, but I just wanted to check
back against 5892.

[Ballot comment]
1.3:

  The specification in this document applies to the IPFIX protocol
  specifications [RFC7011].

I don't think you mean "applies to". I think it should be "is based on" or "depends on", right?

3:

Change "SHOULD be used" to "can be used" and "SHOULD use" to "can use". I don't even know what SHOULD could mean in this context.

      The Observation Domain ID SHOULD be 0 when no specific Observation
      Domain ID is relevant for the entire IPFIX Message...

This disagrees with Section 6. What's the exception to the SHOULD there? Is there a case where it would be non-zero when no specific Observation Domain ID is relevant? Instead of "SHOULD be", how about "is set to"?

4.3:

  Mediators which generate new Records, as in Section 4.2, SHOULD NOT
  use values of Information Elements they do not understand.  If they
  do pass such values, they MUST NOT pass values of unknown Information
  Elements unless all such values are passed on in the original order
  in which they were received.

I can't imagine an exception to that SHOULD NOT. Seems like this should say, "MUST ignore values".

The "MUST NOT...unless" construction can be confusing. I suggest changing this to:

  If a Mediator passes values of Information Elements it does not
  understand, it MUST pass them in the order in which they were
  originally received.
 
5: "...Intermediate Process SHOULD report..." Change "SHOULD" to "will".

8: Maybe someone can explain to me why compliance statements are useful. Then again, probably best to ignore me on that.

[Ballot discuss]
A simple Discuss that you can fix almost without thinking. Although it is entirely editorial, it is important enough to warrant a Discuss

Figure 1 is titled

                    Figure 1: IP Message Header format

But I think it is an IPFIX message header as exported by a mediator.
(i.e. one thing wrong and some missing info).

[Ballot comment]
A few gripes and whinges...

Obviously need to fix the "MUST not" identified by idnits. You shouldn't
punt this sort of thing to the RFC Editor - how are they supposed to
know what the author meant?

---

The shepherd write-up is wrong when it says the reference to 7011 is a
downref. That turns out to be a good thing!

---

I should like hear a little more about implementation plans for this
work. I note the reference to mPlane in Acknowledgements section and in
the Shepherd write-up, but this does not tell me much about
implementation. I am familiar with EC FP7 projects, there deliverables
and their methods; I note that mPlane has a task called "Contribution
to Standard" (T7.2); and I worry that this is purely a standardisation
activity with no basis in code. Of course, maybe mPlane will include an
implementation of a Mediator in which case all is well with the world.

Just adding the extra info would be cool.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ipfix-mediation-protocol-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

1) Have the designated experts for the IPFIX registries reviewed these registrations?

2) Are any of these registrations from the NFv9-compatible range of Information Elements?

IANA understands that upon approval, we're being asked to register five Information Elements at

http://www.iana.org/assignments/ipfix

  Name:  originalExporterIPv4Address
  Description:  The IPv4 address used by the Exporting Process on an
      Original Exporter, as seen by the Collecting Process on an IPFIX
      Mediator.  Used to provide information about the Original
      Observation Points to a downstream Collector.
  Data Type:  ipv4Address
  ElementId:  TBD1
  Status: current
  Requester: THIS RFC
  Revision: 0
  Date: YYYY-MM-DD (date of entry into the registry)


  Name:  originalExporterIPv6Address
  Description:  The IPv6 address used by the Exporting Process on an
      Original Exporter, as seen by the Collecting Process on an IPFIX
      Mediator.  Used to provide information about the Original
      Observation Points to a downstream Collector.
  Data Type:  ipv6Address
  ElementId:  TBD2
  Status: current
  Requester: THIS RFC
  Revision: 0
  Date: YYYY-MM-DD (date of entry into the registry)


  Name:  originalObservationDomainId
  Description:  The Observation Domain ID reported by the Exporting
      Process on an Original Exporter, as seen by the Collecting Process
      on an IPFIX Mediator.  Used to provide information about the
      Original Observation Domain to a downstream Collector.
  Data Type:  unsigned32
  Data Type Semantics:  identifier
  ElementId:  TBD3
  Status: current
  Requester: THIS RFC
  Revision: 0
  Date: YYYY-MM-DD (date of entry into the registry)


  Name:  intermediateProcessId
  Description:  An identifier of an Intermediate Process that is
      unique per IPFIX Device.  Typically, this Information Element is
      used for limiting the scope of other Information Elements.  Note
      that process identifiers may be assigned dynamically; ie., an
      Intermediate Process may be re-started with a different ID.
  Data Type:  unsigned32
  Data Type Semantics:  identifier
  ElementId:  TBD4
  Status: current
  Requester: THIS RFC
  Revision: 0
  Date: YYYY-MM-DD (date of entry into the registry)


  Name:  ignoredFlowRecordTotalCount
  Description:  The total number of received Data Records that the
      Intermediate Process did not process since the (re-)initialization
      of the Intermediate Process; includes only Data Records not
      examined or otherwise handled by the Intermediate Process due to
      resource constraints, not Data Records which were examined or
      otherwise handled by the Intermediate Process but which merely do
      not contribute to any exported Data Record due to the operations
      performed by the Intermediate Process.
  Data Type:  unsigned64
  Data Type Semantics:  totalCounter
  ElementId:  TBD5
  Status: current
  Requester: THIS RFC
  Revision: 0
  Date: YYYY-MM-DD (date of entry into the registry)

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators) to Proposed Standard


The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX
  Mediators'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-10-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies the operation of the IP Flow Information
  Export (IPFIX) protocol specific to IPFIX Mediators, including
  Template and Observation Point management, timing considerations, and
  other Mediator-specific concerns.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol/ballot/


No IPR declarations have been submitted directly on this I-D.

superficial nit that doesn't need immediate attention.

section 1

  The specifications in the IPFIX protocol
  [RFC7011] have not been defined in the context of an IPFIX Mediator
  receiving, aggregating, correlating, anonymizing, etc... Flow Records
  from one or more Exporters.

the elipses and the etc are serving the same purpose I'd probably just use a coma.