Subject: [IPFIX] AD review of draft-ietf-ipfix-mediators-problem-statement

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 2 Feb 2010 18:29:06 +0100

Please find below the AD review of
draft-ietf-ipfix-mediators-problem-statement. The document is in pretty
good shape, but I suggest that the editors review my technical and
editorial comments and address them before deciding whether to revise
the I-D or send the document directly to IETF Last Call. 

Dan

Technical
T1. Section 5.3: 

         One way delay from the correlation of PSAMP Packet Reports from
         different Exporters along a specific path.

I have two issues that are not clear to me at this point:
- why is only the correlation delay between PSAMP packet reports taken
into consideration and not between other type of packets as well? 
- where does this correlation happen - at the destination point at
collectors ingress? 

T2. Section 5.5 cases 1 - what type of link aggregation are we talking
about here? Layer 2 like in IEEE 802.3ad / IEEE 802.1AX? How is an IPFIX
collector aware at all about which physical link in the trunk does a
data record travel through or why would it matter - this should be
completely transparent starting with the second half of layer two
actually. Maybe I mis-understand? 

T3. Section 5.5, Cases 3 and 4 - How are data records originating from
different exporters in the same admin domain different areas, or
different admin domain synchronized in order to be correlated? Is an
unique collector assumed, or some synchronization process between
collectors? (if this is just a requirement and the answer is in some
other place please point me to it). 

T4. Section 5.7 - why are (traditional) fixed telephony and mobile
telephony mentioned here? 

T5. I think that the protection of privacy and integrity of data stores
should be added to the additional threats and vulnerabilities introduced
by mediators taking onto account that Data Retention is listed in 5.7 as
one of the applicability examples. 

Editorial: 

E1. Running id-nits results in the following warnings: 

== You're using the IETF Trust Provisions' Section 6.b License Notice
from
     12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
     http://trustee.ietf.org/license-info/)

 == There are 1 instance of lines with private range IPv4 addresses in
the
     document.  If these are generic example addresses, they should be
changed
     to use any of the ranges defined in RFC3330 (or successor):
192.0.2.x,
     198.51.100.x or 203.0.113.x.

This refers to section 6.1

E2. Section 4.4 -  ' ... made difficult by THE heterogeneous environment
...'

E3. Section 5.1 - '... set OF Flow Keys ...'

E4. Section 5.7 - '... the collecting infrastructure IS described in
section 5.2 ...' 

E5. Section 5.8 - ' ... the bandwidth for TRANSPORTING IPFIX is ... 

E6. Should not Section 6.7 be named 'Exporting the Function Item and
parameters'

E7. Should not Section 7 be named Summary and Conclusions? 

E8. Also in Section 7: s/the management between/the mapping between/

---

From: Atsushi Kobayashi <[email-masked]>
Date: Tue, 09 Feb 2010 01:06:01 +0900

Hi Dan, and all,

Thank you for your comments. Sorry for my late reply.
Please see in-line.

On Tue, 2 Feb 2010 18:29:06 +0100

> into consideration and not between other type of packets as well? 

For example, it can utilize the PSAMP Hash-Based filtering in section
6.2.1.2 in RFC5475. PSAMP Packet Reports, including the packet digest
and the arrival time of the packet at the Observation Point, are reported
to IPFIX Mediation, and then it calculates one way delay after
identifying same digest from different Exporters.

> - where does this correlation happen - at the destination point at

I means the Observation Point along with Exporter path.

I would like to replace it.

One way delay from the correlation of PSAMP Packet Reports from
different Exporters along a specific path. For example, one way delay is
calculated from correlation of two PSAMP Packet Reports including the
packet digest and the arrival time at Observation Point. This cases are
described in section 6.2.1.2 in RFC5475.

> actually. Maybe I mis-understand? 

I just mean IEEE 802.3ad.

Operators commonly want to measure traffic data for trunk link,
whether their observation points are trunk interface or not. In this
case, IPFIX Collector needs to measure traffic volume per trunk link by
aggregating data records observed at physical interface which is
combined in same trunk link.

I think that IPFIX mediator can export the traffic data per trunk link
after aggregating data record including the traffic data per physical
link.

Current description seems sketchy explanation. I would like to replace
it.

o  Cases 1: Spatial Composition within one Observation Domain

For example, to measure the traffic for a single logical interface in
the case where link aggregation exists, Data Records metered at physical
interfaces belonging to the same trunk can be merged.

> other place please point me to it). 

Traffic data per some area within a same admin domain comes from
aggregation of data records based on info related to observation
points. For example, an unique Collector knows where each Explorter
exists, such as west or east, and then it works out traffic data per
area based on Exporter IP address.

In the same way, Traffic data per customer beyond admin domain comes
from aggregation of data records. In this case, an unique Collector
knows the customer in which each Explorter exists.

I assume IPFIX mediators execute it instead for an unique Collector to
reduce the load of Collector. It is just requirement.

These aggregation method is described in section 5.3.2.3 in framework
draft.

> telephony mentioned here? 

As far as I know, originally data retention comes from requirement of
traditional service. I means the starting point for data retension is
traditional service to explain it.

> one of the applicability examples. 

Yes. I would add the following paragraph in Security Consideration
section.

o  Confidentiality protection and data integrity via IPFIX Mediation

To ensure integrity and confidentiality of Data Records, its transport
for Data Records should use Transport Layer Security (TLS) or Datagram
Transport Layer Security (DTLS). However, an IPFIX Collector cannot know
whether received Data Records are transported as encrypted data between
an Original Exporter and an IPFIX Mediator. And an IPFIX Collector can
also not certificate an Original Exporter directly. Some method would be
required to make up for this deficiency.

>      http://trustee.ietf.org/license-info/)

Ok.

> This refers to section 6.1

Ok.

> E3. Section 5.1 - '... set OF Flow Keys ...'

Ok. I will change it as follows.

  A simplest set OF Flow Keys is a fixed 5-tuple of protocol...

> E4. Section 5.7 - '... the collecting infrastructure IS described in
Ok.

> E5. Section 5.8 - ' ... the bandwidth for TRANSPORTING IPFIX is ... 
Ok.

> E6. Should not Section 6.7 be named 'Exporting the Function Item and
Ok. I will rename section 6.7. title.

6.7 IPFIX Mediation Interpretation

> E7. Should not Section 7 be named Summary and Conclusions? 
Ok. I will name the section 7 "Conclusion".

> E8. Also in Section 7: s/the management between/the mapping between/
Ok.

Best Regards,
Atsushi

> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Feb 2010 13:07:13 +0100

Hi Atsushi,

Please see in-line. 

I am expecting for a revised version to be published before sending the
document to IETF Last Call. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Atsushi Kobayashi [mailto:[email-masked]] 
> Sent: Monday, February 08, 2010 6:06 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [IPFIX] AD review of 
> draft-ietf-ipfix-mediators-problem-statement
> 
> 
> Hi Dan, and all,
> 
> > draft-ietf-ipfix-mediators-problem-statement. The document is in 
> > pretty good shape, but I suggest that the editors review my 
> technical 
> > and editorial comments and address them before deciding whether to 
> > revise the I-D or send the document directly to IETF Last Call.
> > 
> > Dan
> > 
> > 
> > Technical
> > T1. Section 5.3: 
> > 
> 6.2.1.2 in RFC5475. PSAMP Packet Reports, including the 
> packet digest and the arrival time of the packet at the 
> Observation Point, are reported to IPFIX Mediation, and then 
> it calculates one way delay after identifying same digest 
> from different Exporters.

Yes, but you did not answer my question. Why only this type of packets
(PSAMP packet reports) and not other type of IPFIX packets can be used
to measure one way delay correlation? 

> One way delay from the correlation of PSAMP Packet Reports 
> from different Exporters along a specific path. For example, 
> one way delay is calculated from correlation of two PSAMP 
> Packet Reports including the packet digest and the arrival 
> time at Observation Point. This cases are described in 
> section 6.2.1.2 in RFC5475.
> 

OK, but please address the question above. 

> > about here? Layer 2 like in IEEE 802.3ad / IEEE 802.1AX? How is an 
> > IPFIX collector aware at all about which physical link in the trunk 
> > does a data record travel through or why would it matter - 
> this should 
> > be completely transparent starting with the second half of 
> layer two 

Please clarify this and add IEEE 802.3ad as Informative Reference. 

> Operators commonly want to measure traffic data for trunk 
> link, whether their observation points are trunk interface or 
> not. In this case, IPFIX Collector needs to measure traffic 
> volume per trunk link by aggregating data records observed at 
> physical interface which is combined in same trunk link.
> 
> I think that IPFIX mediator can export the traffic data per 
> trunk link after aggregating data record including the 
> traffic data per physical link.
> 
> Current description seems sketchy explanation. I would like 
> to replace it.
> 
> For example, to measure the traffic for a single logical 
> interface in the case where link aggregation exists, Data 
> Records metered at physical interfaces belonging to the same 
> trunk can be merged.
> 
OK

> Traffic data per some area within a same admin domain comes 
> from aggregation of data records based on info related to 
> observation points. For example, an unique Collector knows 
> where each Explorter exists, such as west or east, and then 
> it works out traffic data per area based on Exporter IP address.
> 
> In the same way, Traffic data per customer beyond admin 
> domain comes from aggregation of data records. In this case, 
> an unique Collector knows the customer in which each Explorter exists.
> 
> I assume IPFIX mediators execute it instead for an unique 
> Collector to reduce the load of Collector. It is just requirement.
> 
> These aggregation method is described in section 5.3.2.3 in 
> framework draft.

It would be good to mention that unique collectors are assumed.
Otherwise people may try to implement the functions on multiple
collector which would imply usage of expensive time synchronization
processes. 

> As far as I know, originally data retention comes from 
> requirement of traditional service. I means the starting 
> point for data retension is traditional service to explain it.
> 

This explanation is not clear to me. In order for IPFIX to carry
traditional telephony traffic information this information needs to be
translated into IP traffic using some kind of gateway. After that it
does not differ to regular VoIP traffic originated by the gateway. So
how are these cases different from VoIP? 

> > T5. I think that the protection of privacy and integrity of data 
> > stores should be added to the additional threats and 
> vulnerabilities 
> > introduced by mediators taking onto account that Data Retention is 
> > listed in 5.7 as one of the applicability examples.
> > 
> 
> Yes. I would add the following paragraph in Security 
> Consideration section.
> 
> To ensure integrity and confidentiality of Data Records, its 
> transport for Data Records should use Transport Layer 
> Security (TLS) or Datagram Transport Layer Security (DTLS). 
> However, an IPFIX Collector cannot know whether received Data 
> Records are transported as encrypted data between an Original 
> Exporter and an IPFIX Mediator. And an IPFIX Collector can 
> also not certificate an Original Exporter directly. Some 
> method would be required to make up for this deficiency.
> 

OK.

> > E2. Section 4.4 -  ' ... made difficult by THE heterogeneous 
> > environment ...'
> >

---

From: Atsushi Kobayashi <[email-masked]>
Date: Tue, 16 Feb 2010 02:43:39 +0900

Hi Dan, and all,

Thank you for your replay. 
Please see in-line.

On Mon, 15 Feb 2010 13:07:13 +0100

> document to IETF Last Call. 

I will prepare next version.

> to measure one way delay correlation? 

Sorry, I would like to clarify your question. 
This section covers the one way delay associated with observed packets in
PSAMP Exporter. I do not mean one way delay for IPFIX packets, PSAMP packets.

Or do you mean all of relevant functions should be put in? For example,
one way delay for IPTV stream, an IPFIX Exporter filters specified IPTV
session by using property match filtering, and then a Collector
calculates one way delay without hash digest. But, this example uses
PSAMP packet reports as well. Besides it, it is apparently difficult to
get one way delay from general Flow Record. At this stage, I can not
come up with another idea.

> > Records metered at physical interfaces belonging to the same 

I will add it as Informative Reference.

 For example, to measure the traffic for a single logical 
 interface in the case where link aggregation [IEEE802.3ad] exists,
 Data Records metered at physical interfaces belonging to the same 
 trunk can be merged.

> collector which would imply usage of expensive time synchronization

I will replace it as follows.

o  Cases 4: Spatial Composition across administrative domains

Data Records metered across administrative domains, such as across
different customer networks or different ISP networks, can be merged.
For example, an unique Collector knows in which customer network an
Explorter exists, and then works out the traffic data per customer based
on the Explorter IP address.

> how are these cases different from VoIP? 

Hmm, they are not much different than traditional. So, I will improve it
more concisely.

[Old]
Data retention services examples are the following:

   o  Fixed telephony (includes fixed voice calls, voicemail, and
      conference and data calls)

   o  Mobile telephony (includes mobile voice calls, voicemail,
      conference and data calls, SMS, and MMS)

   o  Internet telephony (includes every multimedia session associated
      with IP multimedia services)

   o  Internet e-mail

   o  Internet access

Data retention for Internet access services in particular requires a
measurement system with reliable export and huge storage as the data 
must be available for a long period of time, typically at least six 
months.

[New]
Data retention examples relevant to IP networks are the following:

   o  Internet telephony (includes every multimedia session associated
      with IP multimedia services, such as VoIP, IPTV)

   o  Internet e-mail

   o  Internet access

Data retention for these services in particular has  been required a
measurement system with reliable export and huge storage as the data
must be available for a long period of time, typically at least six
months. 

> > method would be required to make up for this deficiency.

Regards,
Atsushi

---

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Feb 2010 18:57:59 +0100

I deleted much of the stuff we agreed about. 

Thanks and Regards,

Dan

> Sent: Monday, February 15, 2010 7:44 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re[2]: [IPFIX] AD review of 

...

> > > 6.2.1.2 in RFC5475. PSAMP Packet Reports, including the packet 
> > > digest and the arrival time of the packet at the 
> Observation Point, 
> > > are reported to IPFIX Mediation, and then it calculates one way 
> > > delay after identifying same digest from different Exporters.
> > 
> This section covers the one way delay associated with 
> observed packets in PSAMP Exporter. I do not mean one way 
> delay for IPFIX packets, PSAMP packets.

Why only PSAMP? This is my question. Section 5.3 is titled 'Correlation
for Data Records' so in a IPFIX document I would expect it to be about
any IPFIX data records, not only PSAMP. If you limit the scope to PSAMP
you should title it 'Correlation of PSAMP Data Records'. 

> 
> Or do you mean all of relevant functions should be put in? 
> For example, one way delay for IPTV stream, an IPFIX Exporter 
> filters specified IPTV session by using property match 
> filtering, and then a Collector calculates one way delay 
> without hash digest. But, this example uses PSAMP packet 
> reports as well. Besides it, it is apparently difficult to 
> get one way delay from general Flow Record. At this stage, I 
> can not come up with another idea.
> 

....

OK.

OK. 

OK.

---

From: Atsushi Kobayashi <[email-masked]>
Date: Tue, 16 Feb 2010 19:08:16 +0900

Hi Dan,

> you should title it 'Correlation of PSAMP Data Records'. 

Section 5.3 is not limited to just one-way delay, it enumerates some
examples, such as average/maximum/minimum values, rate-limiting ratio,
and BGP attributes. Even though one-way delay or packet inter-arrival
time comes from only PSAMP packet report, the rest are applied to both.
Thus, I named it "Correlation for Data Records". Is it OK?

Regards,
Atsushi

---

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 16 Feb 2010 11:16:55 +0100

> Sent: Tuesday, February 16, 2010 12:08 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re[4]: [IPFIX] AD review of 
> > > This section covers the one way delay associated with observed 
> > > packets in PSAMP Exporter. I do not mean one way delay for IPFIX 
> > > packets, PSAMP packets.
> > 
> > Why only PSAMP? This is my question. Section 5.3 is titled 
> > 'Correlation for Data Records' so in a IPFIX document I 
> would expect 
> > it to be about any IPFIX data records, not only PSAMP. If you limit 
> > the scope to PSAMP you should title it 'Correlation of 
> PSAMP Data Records'.
> > 
> 
> Section 5.3 is not limited to just one-way delay, it 
> enumerates some examples, such as average/maximum/minimum 
> values, rate-limiting ratio, and BGP attributes. Even though 
> one-way delay or packet inter-arrival time comes from only 
> PSAMP packet report, the rest are applied to both.

OK, I got it. Thanks for your patience in explaining the details. 

Dan