Subject: [ipfix] Last Call Comments (was: FW: [Bernard Aboba] Re: [secdir] draft-ietf-ipfix-as-08.txt)

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 14 Jun 2006 20:30:06 +0300

Please consider the attached comments from Bernard Adoba from the AAA
and security perspective as Last Call comments. 

Thanks and Regards,

Dan

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, June 14, 2006 4:02 PM
To: [email-masked]; Romascanu, Dan (Dan)
Subject: [Bernard Aboba] Re: [secdir] draft-ietf-ipfix-as-08.txt

This seems like more of a AAA issue than a security issue.
Are either of you interested in taking these comments under
consideration?

Subject: Re: [secdir] draft-ietf-ipfix-as-08.txt
From: "Bernard Aboba" <[email-masked]>
To: "Barbara Fraser" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, "Sam Hartman" <[email-masked]>, <[email-masked]>
Date: Tue, 13 Jun 2006 21:44:14 +0300

Overview

Overall, what is odd about this applicability statement is that it does 
not clearly lay out the limits of applicability of IPFIX.  Instead, it 
suggests lots of potential usage scenarios, without clearly 
indicating the applicability limits. 

At various points, this document crosses the line into describing
usage-based billing scenarios for which IPFIX was not designed. 
Since the document indicates that IPFIX does not meet the reliability
requirements stated in RFC 2975, the usage of IPFIX in usage-based
billing scenarios is potentially dangerous, resulting in violation of 
financial reporting requirements.  The document needs to be more clear 
about the limitations of IPFIX in usaged-based billing
scenarios. 

Section 2.1

    Usage based accounting is one of the major applications for 
    which the IPFIX protocol has been developed. 

Later on in the document, it is stated that IPFIX does not meet
the reliability requirements for usage-based billing.  Given this, 
I'd suggest that the document needs to be careful throughout in
its description of accounting applications of IPFIX.  For example,
the term "usage based accounting" needs to be clarified to make it 
clear that we are not talking about usage-based billing.  It might 
make sense to use the term "usage reporting" instead, to make it
clear that bills are not being generated from the information. 

"   For accounting purposes, it would be advantageous to have the 
    ability to use IPFIX flow records as accounting input in an AAA 
    infrastructure. AAA servers then could provide the mapping 
    between user and flow information."

I'm not clear what is being suggested here.  Later on, it is 
suggested that IPFIX flow records might be carried within 
Diameter & RADIUS.  However, IPFIX already defines a transport for 
this information, as I understand it.  Perhaps what is meant here is 
that a monitoring & report system could combine AAA authentication 
information (User-Name + Framed-IP-Address) with information obtained 
from IPFIX to produce more useful reports.  However, that is something
that is distinct from "AAA infrastructure". 

    Note that the reliability requirements defined in [RFC3917] are 
    not sufficient to guarantee the level of reliability that is 
    needed for many usage-based accounting systems. Particular 
    reliability requirements for accounting systems are discussed in 
    [RFC2975].  

If IPFIX does not guarantee a sufficient level of reliability for 
usage-based billing, then this needs to be called out specifically in the
applicability statement, and the document needs to clarified at various
points.

It is important for the document to be clear about this, because
there are financial reporting (and security) requirements surrounding
accounting systems, some of which are described in RFC 2975.  Where
usage data is used in the generation of bills, packets carrying that
information effectively represent money -- and packet loss translates
directly to revenue loss.  Accounting systems that "lose" revenue due to 
design deficiencies are likely to draw attention from regulators, 
and shareholders.  Therefore the IETF needs to be particularly careful 
when reviewing documents which relate to these systems. 

Section 2.1.1

    Let's suppose someone has a Service Level Agreement (SLA) in a 
    DiffServ network requiring accounting based on traffic volume. 

This seems to suggest that a bill is being generated from IPFIX
data, which contradicts the applicability statement made in Section 2.1. 

Section 3.4

    DIAMETER is used for the transfer of accounting 
    records. In order to form accounting records for usage-based 
    accounting measurement data from the network is required. IPFIX 
    defines a protocol to export such data from routers, measurement 
    probes and other devices. Therefore it looks promising to 
    connect those two architectures. 

Diameter accounting was specifically designed to meet the 
reliability requirements described in RFC 2975, whereas IPFIX
was not.   Therefore "connecting those two architectures" in
usage-based billing situations could result in a system that
no longer meets financial reporting requirements. 

    As shown in section 2.1 accounting can be realized without an 
    AAA infrastructure. Accounting applications can directly 
    incorporate an IPFIX collecting process to receive IPFIX records 
    with information about the transmitted volume. 

Given the reliability constraints described earlier, using IPFIX
as input to a usage-based billing system is inappropriate. 

    IPFIX 
    records can provide the input for AAA accounting functions and 
    provide the basis for the generation of DIAMETER accounting 
    records. 

This has the potential to introduce unreliability into Diameter
accounting, due to loss of packets within IPFIX.  Therefore
if this is going to be suggested, the limitations need to 
made clear -- namely that this is not appropriate
in usage-based billing environments. 

    Further potential features include... 
    facilitating the secure authorized exchange of 
    DIAMETER accounting records with neighbor domains. 

Diameter already supports TLS-based security, so it is not clear
to me what IPFIX can add here.