Subject: RE: [ipfix] IPFIX requirements - final changes

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Tue, 27 May 2003 12:34:45 -0700

I agree with Nevil, Tal and Benoit on this...

-- Jeff Meyer

> -----Original Message-----
> From: Nevil Brownlee [mailto:[email-masked]]
> Sent: Tuesday, May 27, 2003 12:28 PM
> To: MEYER,JEFFREY D (HP-Cupertino,ex1)
> Cc: [email-masked]
> Subject: RE: [ipfix] IPFIX requirements - final changes
> 
> 
> Responding to Jeff, who said:
> 
> >   I agree w/ Tal and Benoit on this one.
> 
> The IESG comment was about confidentiality and anonymisation in IPFIX
> being "so optional."  Maybe a better way to improve this would be to
> write a few parargraphs referring to RFC 2975, making it clear that 
> building an accounting system invloves much more than just selecting 
> an export protocol (i.e. other techniques like using a 
> separate network
> may be sufficient in many cases), which is why the IPFIX 
> requirements only
> say SHOULD for these.  Of course, if a vendor implements them, users
> can decide whether or not to actually use them!  If others 
> agree with this,
> I could write some text in a day or two ...
> 
> Juergen's other proposed changes to the draft look OK to me.
> 
> Cheers, Nevil
> 
> --------------------------------------------------------------
> ---------
>    Nevil Brownlee                   Director, Technology Development
>    Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
> 
> 
> -------------------------------------------------
> This mail sent through University of Auckland
> http://www.auckland.ac.nz/
> 

--
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: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 28 May 2003 13:36:12 -0400

Hi,

  How about a little "separation of concern" on the topics of 
anonymization and confidentiality?

  IPSEC provides a means to make confidential either UDP based or
TCP based protocol conversations (presumably SCTP as well).  Can
we simply say that the protocol itself will not introduce any 
specific confidentiality mechanisms, but will rely on underlying
mechanisms?

  As far as anonymization, is this a protocol issue or a data model
issue?  Since the protocol itself can carry more or less arbitrary
sets of structured (first normal form) information.  Define new 
attributes for:

   anonSourceAddress
   anonDestAddress
   anonSourceAddressV6
   anonDestAddressV6

  Since these are the only user identifying fields in the data model
today (that I know of), then creating their anonymous analog (which
presumes some model on the exporter/observer, to transform addr's)
should be sufficient.

Regards,

  Jeff Meyer

> From: Juergen Quittek [mailto:[email-masked]]
> Sent: Wednesday, May 28, 2003 6:28 AM
> To: Sebastian Zander
> Subject: Re: [ipfix] IPFIX requirements - final changes
> 
> 
> Sebastian,
> 
> -- Sebastian Zander wrote on 28 May 2003 12:18 +0200:
> 
> > Hi Juergen,
> >
> > i think your second paragraph is a very good idea. But i don't
> > understand the last 2 sentences. My understanding is that the ipfix
> > requirement draft defines the ipfix protocol requirements. 
> So i don't
> > understand why the protocol specification must cover all 
> requirements.
> > E.g. when a requirementis optional why must it be covered 
> in the protocol
> > specification?
> 
> If the requirement doc says "the exporter MAY anonymize", then the
> protocol specification MUST support anonymization in order to make
> sure, that anonymization is interoperable. For example the protocol
> spec MUST define how to inform a collecting process that the data it
> receives is anonymized. Analogously, the protocol spec should specify
> how to encrypt.
> 
> In both cases, the protocol specification can state that a concrete
> implementation of the protocol MAY support features that serve
> anonymization. Then an implementor can choose whether or not 
> to implement
> this OPTIONAL feature of the protocol.
> 
> > I agree to say its a MUST for the protocol but not all exporters
> > and collectors must support it.
> 
> Agreed.
> 
> > But i do *not* agree at all that in general anonymization and
> > confidentiality is not needed in a LAN. Anonymization can 
> be required
> > in a LAN and even in a LAN confidentiality may be needed because i
> > don't want everybody who has access to my LAN to have access to my
> > IPFIX data.
> 
> Also agreed.
> 
> Best wishes,
> 
>     Juergen
> 
> > Cheers,
> >
> > Sebastian
> >
> > Juergen Quittek wrote:
> >> Tal, Reinaldo, and Benoit,
> >>
> >> Do we all have the following in mind?
> >>
> >>   Anonymization and confidentiality MUST be covered by the
> >>   protocol specification.  But the protocol specifiction
> >>   specification defines it as a MAY feature (anonymization)
> >>   or SHOULD feature (confidentiality) for IPFIX protocol
> >>   implementations.
> >>
> >> I guess this is what the IESG reviewers were referring to.
> >>
> >> What is probably missing in the requirements document is a
> >> statement like the following:
> >>
> >>   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
> >>   independent of the significance of the requirement,
> >>   which can be MANDATOYRY, RECOMMENDED, or OPTIONAL.
> >>   Note that the protocol specification itself also assigns
> >>   significance attributes to its features, such that a
> >>   protocol implementation does not necessarily need to
> >>   implement all features.
> >>
> >> Any comment on this?
> >>
> >>    Juergen
> >>
> >>
> >> -- Tal Givoly wrote on 26 May 2003 09:42 -0700:
> >>
> >>> Juergen,
> >>>
> >>> I agree with Benoit - it doesn't make sense to make 
> confidentiality and
> >>> anonymization mandatory. In many deployments, there could 
> be physical and
> >>> other security measures that addresses these issues.
> >>>
> >>> Tal
> >>>
> >>> From: majordomo listserver 
> [mailto:[email-masked]]On Behalf
> >>> Of Benoit Claise
> >>> Sent: Monday, May 26, 2003 8:02 AM
> >>> To: Juergen Quittek
> >>> Subject: Re: [ipfix] IPFIX requirements - final changes
> >>>
> >>>
> >>> Juergen,
> >>>
> >>>> 
> ==============================================================
> ==========
> >>>> 12. Confidentiality from SHOULD to MUST
> >>>> 
> ==============================================================
> ==========
> >>>> Problem Description:
> >>>> 
> ----------
> >>>> 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.
> >>>> 
> ==============================================================
> ==========
> >>>> Suggested solution:
> >>>> 
> ----------
> >>>>   change confidentiality requirement in section 6.3.3
> >>>>   from SHOULD to MUST
> >>>> 
> ==============================================================
> ==========
> >>>> Status: solution to be agreed on
> >>>> 
> ==============================================================
> ==========
> >>>
> >>>
> >>> I'm just wondering if a MUST is not a little bit extreme.
> >>> The draft would become:
> >>>    "Confidentiality of flow specific data transferred 
> from an exporting
> >>>    process to a collecting process MUST be ensured."
> >>> We all agree that over the Internet confidentiality is 
> compulsory but
> >>> this sentence would mean that even in a private LAN or 
> environment, we
> >>> must have confidentiality to be IPFIX compliant. And we 
> know that, with
> >>> the software based encryption, the throughput would be 
> lowered. Ok, then
> >>> we should have an crypto engine in hardware on the 
> exporter to export
> >>> the numerous flow export packets but there is a price to it.
> >>> My point is that, as Confidentiality is not needed in all 
> cases, why
> >>> make it a MUST?
> >>>
> >>>>
> >>>>
> >>>>
> >>>> 
> ==============================================================
> ==========
> >>>> 13. Anonymization from MAY to MUST
> >>>> 
> ==============================================================
> ==========
> >>>> Problem Description:
> >>>> 
> ----------
> >>>> 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.
> >>>> 
> ==============================================================
> ==========
> >>>> Suggested solution:
> >>>> 
> ----------
> >>>>   change anonymization requirement in section 6.7 from 
> MAY to MUST
> >>>> 
> ==============================================================
> ==========
> >>>> Status: solution to be agreed on
> >>>> 
> ==============================================================
> ==========
> >>>
> >>>
> >>> Again, I have the same type of comments. Anonymization is 
> not required
> >>> in all cases. So why make it a MUST?
> >>>
> >>> Regards, Benoit.
> >>>
> >>>
> >>>
> >>> --
> >>> Help        mailto:[email-masked] and say 
> "help" in message
> >>> body
> >> Help        mailto:[email-masked] and say 
> "help" in message
> >> body
> > Sebastian Zander                         E-mail: 
> [email-masked]
> > Fraunhofer FOKUS / METEOR                Tel: +49-30-3463-7287
> > Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
> > D-10589 Berlin, Germany                  
www.fokus.fraunhofer.de/usr/sebastian.zander

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