From majordomo@mil.doit.wisc.edu  Fri Jan  9 10:44:27 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07326
	for <ipfix-archive@lists.ietf.org>; Fri, 9 Jan 2004 10:44:22 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AeyKN-0001CN-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 09 Jan 2004 09:13:35 -0600
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AeyKM-0001CE-00
	for ipfix@net.doit.wisc.edu; Fri, 09 Jan 2004 09:13:34 -0600
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i09FCnG09181
	for <ipfix@net.doit.wisc.edu>; Fri, 9 Jan 2004 09:12:55 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <ZPPAFFAG>; Fri, 9 Jan 2004 16:12:47 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155033D3ACA@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Juergen Quittek <quittek@ccrle.nec.de>, ipfix@net.doit.wisc.edu
Subject: [ipfix] IESG comments on: draft-ietf-ipfix-reqs-13.txt
Date: Fri, 9 Jan 2004 16:12:44 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

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

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

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.
  
  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'.

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.

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

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

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.

(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.

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?

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.

      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?

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?

  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?  

      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.

10.  Security Considerations

  An IPFIX protocol must be capable to transport data over the public

>> Editorial: s/capable to transport/capable of transporting

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

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan  9 18:07:52 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26887
	for <ipfix-archive@lists.ietf.org>; Fri, 9 Jan 2004 18:07:52 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Af5ZF-0006bQ-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 09 Jan 2004 16:57:25 -0600
Received: from zcamail04.zca.compaq.com ([161.114.32.104])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Af5ZE-0006bL-00
	for ipfix@net.doit.wisc.edu; Fri, 09 Jan 2004 16:57:24 -0600
Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.46])
	by zcamail04.zca.compaq.com (Postfix) with ESMTP
	id 18E555B96; Fri,  9 Jan 2004 14:57:23 -0800 (PST)
Received: from cacexc03.americas.cpqcorp.net ([16.92.1.27]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0);
	 Fri, 9 Jan 2004 14:57:21 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3D703.EFB5394A"
Subject: RE: [ipfix] Option templates issues - Consensus?
Date: Fri, 9 Jan 2004 14:57:20 -0800
Message-ID: <A747B346BDCCAB45831C24F0CD7C7F09177D68@cacexc03.americas.cpqcorp.net>
Thread-Topic: [ipfix] Option templates issues - Consensus?
Thread-Index: AcPV4ZefCRrklMsxRyeyyWBdNOJWkgBIDgpA
From: "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>
To: "Benoit Claise" <bclaise@cisco.com>
Cc: "Mark Fullmer" <maf@eng.oar.net>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
X-OriginalArrivalTime: 09 Jan 2004 22:57:21.0215 (UTC) FILETIME=[F040ACF0:01C3D703]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3D703.EFB5394A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
  I agree that there is a distinction between protocol extensions (e.g. =
a hello message) and special (options) information element extensions.
=20
  So I'm OK with this proposal.  The mechanism for header extensions I =
think needs some more details.
=20
  The current protocol spec seems to define exactly one message type =
with four possible payload subtypes (template, option template,
  data, option data).  These payloads may be intermixed.
=20
  The mechanism for adding extensions would seem to be based on the =
reserved range of 0-255 for templateId's.  Currently 0 and 1
  are used for flow templates and option templates.  Flow data and =
option data are distinguished solely based on previous id assignments
  by the respective templates.
=20
  So I guess the proposal would be a hello message or other header =
extensions would utilize other values in the range 2-255.  Is this
  correct?
=20
Regards,
=20
  Jeff Meyer

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, January 08, 2004 4:19 AM
To: Meyer, Jeffrey D (http://usage.fc.hp.c)
Cc: Mark Fullmer; 'Ipfix Wg' (E-mail)
Subject: Re: [ipfix] Option templates issues - Consensus?


Hi,

In order to progress with the protocol draft... is there a consensus for =
the following concepts?

There are two issues here=20

  1) How to provide extra information about the flow data and metering=20
     process.=20

  2) How to allow for protocol extensions.=20

1) How to provide extra information about the flow data and metering =
process.=20
Typical example: the meterstats.
An option template will be used
The protocol draft will specify what the minimal set of data types is =
required
A new data type (referred to ipfixOption by Jeff) would be used to =
identify specific options templates
This would help the collector answering the question:
switch (ipfixOption)=20
  case METER_STATS
    do that.=20
  case ...=20
    do something else.=20

2) How to allow for protocol extensions.=20
Typical example: hello, exporter ID, authentication, etc...
No options template: an extension to the header will be used.

Regards, Benoit.


Mark,



  Not having seen requirements or discussion for "proxies", I'm having a =
hard time conceptualizing this new requirement.



  Since option template Id's and flow record template Id's are currently =
dynamically determined, I guess what you are arguing is that options =
should somehow be fixed.



  Since a "hello" option has not even been defined to date, and your use =
case seems to be centered around reliable failover, I think there are a =
lot of tangled concerns going on here.  Could you elaborate a bit more =
on this scenario?



-- Jeff



-----Original Message-----

From: Mark Fullmer [ mailto:maf@eng.oar.net]

Sent: Tuesday, January 06, 2004 10:36 PM

To: Meyer, Jeffrey D ( http://usage.fc.hp.c)

Cc: 'Ipfix Wg' (E-mail)

Subject: Re: [ipfix] Option templates issues





Consider a proxy.  If the proxy needs to use an option ID to say=20

maintain

HELLO's for a reliable fail-over mechanism it will have to pick a=20

template ID

that potentially clashes with a future one used by an exporter.  So now

a proxy needs to track all inbound template ID's, map them to outbound=20

ID's,

and rewrite fields in the messages that refer to the template ID's.



mark



On Dec 23, 2003, at 2:12 PM, Meyer, Jeffrey D ( http://usage.fc.hp.c)=20

wrote:



 =20

Mark,



  Agreed, it is a choice, and both will work, it is a questions of=20

anticipated extensibility.  Fewer fields in the header and most=20

information elements defined in a consistent manner seems to me to=20

address the approach of "Make it as simple as possible and no=20

simpler".



  Since the requirement appears to be addressable with a single=20

mechanism, i.e. a flag distinguishing options from flow elements, and=20

reusing the information modeling, I still don't see the benefit in=20

introducing more mechanisms which need to be implemented and tested on=20

both ends.



-- Jeff



-----Original Message-----

From: Mark Fullmer [ mailto:maf@eng.oar.net]

Sent: Tuesday, December 23, 2003 10:11 AM

To: Meyer, Jeffrey D ( http://usage.fc.hp.c)

Cc:  ipfix@net.doit.wisc.edu; Benoit Claise

Subject: Re: [ipfix] Option templates issues





There are two issues here



   1) How to provide extra information about the flow data and metering

      process.



   2) How to allow for protocol extensions.



If we add a required "key" or "command" field to the options templates

then I think what we have will work given the proper text

describing what IE's MAY, SHOULD, and MUST be present in an options

template with a specific key.  We may want to even have a separate

IE namespace for the options....



The protocol extension I'm still of the opinion should be handled

with an extensible header.  Examples of protocol extensions could be



    Reliable fail-over.



    Authentication.



    The optional time stamp for the split-time model.



    Hooks for proxies.



    Future unanticipated extensions.



And yes, all of this could be stuffed in an options template but the

same

argument could be used to do away with the protocol header entirely.



mark





On Dec 22, 2003, at 11:17 AM, Meyer, Jeffrey D ( http://usage.fc.hp.c)

wrote:



   =20

Hi,



  Again, I'd point out, that as Benoit indicates, there are likely to

be different things we want to send as "options".



  Rather than inventing an entirely new model, just make option a

flag on the template and REUSE what we already have for data records.

It's that simple!



-- Jeff



-----Original Message-----

From: majordomo listserver [ mailto:majordomo@mil.doit.wisc.edu]On

Behalf

Of Benoit Claise

Sent: Monday, December 22, 2003 4:04 AM

To: Mark Fullmer

Cc:  ipfix@net.doit.wisc.edu

Subject: Re: [ipfix] Option templates issues





Mark,



[sorry for the delay, i've been absent from the list for a while]



I understand the concern but let me ask a few questions.

What if the metering process can't "meter" one of them? Ex: flows not

exported due to resource starvation

What if we would like to export some extra data types? Ex: IPv6=20

packets

and bytes dropped

So what if the METERSTAT struct is slightly modified?



Ganesh had a good point I think:

    If the group can come up with fixed structs that you mentioned

below,

    then I think what you propose can be adopted.



Aren't we going to spend a long time to determine what MUST be=20

exported

in this/those structure(s)?

What you defined in your METERSTAT makes perfectly from a collector

point of view but will not always be possible to collect on the

exporter?

And it does perfectly sense now, but what about in 1 year? So would we

have a new data type with a new slightly different structure?



I'm just wondering what we should say in the protocol draft:

    1. SHOULD export a METERSTAT data type(as described in your=20

email)?

What if one data type can't be exported, we don't send any metering

stats "message"?

    2. MUST export a metering statistics Options Templates that SHOULD

contain lost_flows, lost_flows_pkts, lost_flows_bytes, lost_pkts,

lost_bytes, time.

    3. MUST export a metering statistics Options Templates that MUST

contain X, Y, and SHOULD contain Z

    4. MUST export a metering statistics Options Templates that=20

contain

at least X, Y



Actually, I think the flexibility of the Options Template is=20

benefitial

for any data types.



Now, this is a different story for the Hello, Failover, etc... types=20

of

messages that you spoke about, as the goal is totally different!



Regards, Benoit.



     =20

I'd like to propose an alternative mechanism for sending auxiliary

data such

as time synch messages, protocol hellos (needed for fail-over),

metering

process loss statistics (ie packets/flows lost due to resource

starvation),

etc.



The existing framework allows "other" data to be sent in options

templates.

Take for example a metering process stat message.  Lets say the

metering

process will periodically report statistics such as



  struct METERSTAT {

    u_int32_t lost_flows;       /* flows not exported due to resource

starvation */

    u_int32_t lost_flows_pkts;  /* packets in the lost flows */

    u_int32_t lost_flows_bytes; /* bytes in the lost flows */

    u_int32_t lost_pkts;   /* packets dropped by metering process */

    u_int32_t lost_bytes;  /* bytes dropped by metering process */

    time_t    now;         /* when this record was generated */

  };



  The question becomes how to encode this with an options template.



  Each field in the record could have a type (6 types), then the

options template

  would list each of the 6 types.  The problem here is during

decoding.  What

  will the collector do if only 5 of these items show up.  The packet

decode

  process is also not very straightforward when just data is sent

(other option

  fields could be in the same template) because it will have to=20

figure

out

  what to do based on the field type and there's no way to group

fields.

       =20

  The other option is to call METERSTAT a type (of length 24).  Now

the

  decode process can key off of the type and all the fields will

always be

  there because METERSTAT is fixed and defined in the protocol

document just

  like other fields like PACKETS, BYTES, PROTOCOL, etc.  The issue I

have here

  is why are we bothering with a template/data model for this.  Why

not just

  use traditional TLV's.



  So what I'd like to see (I think) is to take one of the existing

reserved

  flowset ID's, lets say 3 and use it for generic TLV data encodings.

Then

  define structured data in the protocol such as METERSTAT.  IMHO=20

this

allows us

  to address a number of other issues including how to add HELLO's=20

for

the

  (optional) reliable failover, how to add aux flags like "this is

potentially

  a duplicate PDU because I failed over", etc.



  The TLV encodings would only be used for the low bit-rate protocol

messages,

  NOT the high bandwidth flow data.  I'm also not proposing the=20

option

templates

  go away, just that we use a more traditional method for encoding=20

the

non flow

  data.



mark







--=20

Help         mailto:majordomo@net.doit.wisc.edu and say "help" in

message body

Unsubscribe  mailto:majordomo@net.doit.wisc.edu and say

"unsubscribe ipfix" in message body

Archive      http://ipfix.doit.wisc.edu/archive/

       =20





--

Help         mailto:majordomo@net.doit.wisc.edu and say "help" in

message body

Unsubscribe  mailto:majordomo@net.doit.wisc.edu and say

"unsubscribe ipfix" in message body

Archive      http://ipfix.doit.wisc.edu/archive/



     =20





--

Help         mailto:majordomo@net.doit.wisc.edu and say "help" in =
message body

Unsubscribe  mailto:majordomo@net.doit.wisc.edu and say

"unsubscribe ipfix" in message body

Archive      http://ipfix.doit.wisc.edu/archive/

 =20



------_=_NextPart_001_01C3D703.EFB5394A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;=20
I agree that there is a distinction between protocol extensions (e.g. a =
hello=20
message) and special (options) information element=20
extensions.</FONT></SPAN></DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;=20
So I'm OK with this proposal.&nbsp; The mechanism for header extensions =
I think=20
needs some more details.</FONT></SPAN></DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;=20
The current protocol spec seems to define exactly one message type with =
four=20
possible payload subtypes (template, option =
template,</FONT></SPAN></DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;=20
data, option data).&nbsp; These payloads may be =
intermixed.</FONT></SPAN></DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;=20
The mechanism for adding extensions would seem to be based on the =
reserved range=20
of 0-255 for templateId's.&nbsp; Currently 0 and 1</FONT></SPAN></DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;=20
are used for flow templates and option templates.&nbsp; Flow data and =
option=20
data are distinguished solely based on previous id=20
assignments</FONT></SPAN></DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;=20
by the respective templates.</FONT></SPAN></DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;=20
So I guess the proposal would be a hello message or other header =
extensions=20
would utilize other values in the range 2-255.&nbsp; Is =
this</FONT></SPAN></DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;=20
correct?</FONT></SPAN></DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D787074222-09012004><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;=20
Jeff Meyer</FONT></SPAN></DIV>
<BLOCKQUOTE>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Benoit Claise=20
  [mailto:bclaise@cisco.com]<BR><B>Sent:</B> Thursday, January 08, 2004 =
4:19=20
  AM<BR><B>To:</B> Meyer, Jeffrey D (http://usage.fc.hp.c)<BR><B>Cc:</B> =
Mark=20
  Fullmer; 'Ipfix Wg' (E-mail)<BR><B>Subject:</B> Re: [ipfix] Option =
templates=20
  issues - Consensus?<BR><BR></FONT></DIV>Hi,<BR><BR>In order to =
progress with=20
  the protocol draft... is there a consensus for the following=20
  concepts?<BR><BR>There are two issues here <BR><BR>&nbsp; 1) How to =
provide=20
  extra information about the flow data and metering=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp; process. <BR><BR>&nbsp; 2) How to allow =
for=20
  protocol extensions. <BR><BR><SPAN style=3D"TEXT-DECORATION: =
underline">1) How=20
  to provide extra information about the flow data and metering process. =

  </SPAN><BR>Typical example: the meterstats.<BR>An option template will =
be=20
  used<BR>The protocol draft will specify what the minimal set of data =
types is=20
  required<BR>A new data type (referred to ipfixOption by Jeff) would be =
used to=20
  identify specific options templates<BR>This would help the collector =
answering=20
  the question:<BR>switch (ipfixOption) <BR>&nbsp; case=20
  METER_STATS<BR>&nbsp;&nbsp;&nbsp; do that. <BR>&nbsp; case ...=20
  <BR>&nbsp;&nbsp;&nbsp; do something else. <BR><SPAN=20
  style=3D"TEXT-DECORATION: underline"><BR>2) How to allow for protocol=20
  extensions. <BR></SPAN>Typical example: hello, exporter ID, =
authentication,=20
  etc...<BR>No options template: an extension to the header will be=20
  used.<BR><BR><SPAN style=3D"FONT-FAMILY: monospace">Regards, =
Benoit.</SPAN><BR>
  <BLOCKQUOTE=20
  =
cite=3DmidA747B346BDCCAB45831C24F0CD7C7F09177D3F@cacexc03.americas.cpqcor=
p.net=20
  type=3D"cite"><PRE wrap=3D"">Mark,

  Not having seen requirements or discussion for "proxies", I'm having a =
hard time conceptualizing this new requirement.

  Since option template Id's and flow record template Id's are currently =
dynamically determined, I guess what you are arguing is that options =
should somehow be fixed.

  Since a "hello" option has not even been defined to date, and your use =
case seems to be centered around reliable failover, I think there are a =
lot of tangled concerns going on here.  Could you elaborate a bit more =
on this scenario?

-- Jeff

-----Original Message-----
From: Mark Fullmer [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:maf@eng.oar.net">mailto:maf@eng.oar.net</A>]
Sent: Tuesday, January 06, 2004 10:36 PM
To: Meyer, Jeffrey D (<A class=3Dmoz-txt-link-freetext =
href=3D"http://usage.fc.hp.c">http://usage.fc.hp.c</A>)
Cc: 'Ipfix Wg' (E-mail)
Subject: Re: [ipfix] Option templates issues


Consider a proxy.  If the proxy needs to use an option ID to say=20
maintain
HELLO's for a reliable fail-over mechanism it will have to pick a=20
template ID
that potentially clashes with a future one used by an exporter.  So now
a proxy needs to track all inbound template ID's, map them to outbound=20
ID's,
and rewrite fields in the messages that refer to the template ID's.

mark

On Dec 23, 2003, at 2:12 PM, Meyer, Jeffrey D (<A =
class=3Dmoz-txt-link-freetext =
href=3D"http://usage.fc.hp.c">http://usage.fc.hp.c</A>)=20
wrote:

  </PRE>
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Mark,

  Agreed, it is a choice, and both will work, it is a questions of=20
anticipated extensibility.  Fewer fields in the header and most=20
information elements defined in a consistent manner seems to me to=20
address the approach of "Make it as simple as possible and no=20
simpler".

  Since the requirement appears to be addressable with a single=20
mechanism, i.e. a flag distinguishing options from flow elements, and=20
reusing the information modeling, I still don't see the benefit in=20
introducing more mechanisms which need to be implemented and tested on=20
both ends.

-- Jeff

-----Original Message-----
From: Mark Fullmer [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:maf@eng.oar.net">mailto:maf@eng.oar.net</A>]
Sent: Tuesday, December 23, 2003 10:11 AM
To: Meyer, Jeffrey D (<A class=3Dmoz-txt-link-freetext =
href=3D"http://usage.fc.hp.c">http://usage.fc.hp.c</A>)
Cc: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</A>; =
Benoit Claise
Subject: Re: [ipfix] Option templates issues


There are two issues here

   1) How to provide extra information about the flow data and metering
      process.

   2) How to allow for protocol extensions.

If we add a required "key" or "command" field to the options templates
then I think what we have will work given the proper text
describing what IE's MAY, SHOULD, and MUST be present in an options
template with a specific key.  We may want to even have a separate
IE namespace for the options....

The protocol extension I'm still of the opinion should be handled
with an extensible header.  Examples of protocol extensions could be

    Reliable fail-over.

    Authentication.

    The optional time stamp for the split-time model.

    Hooks for proxies.

    Future unanticipated extensions.

And yes, all of this could be stuffed in an options template but the
same
argument could be used to do away with the protocol header entirely.

mark


On Dec 22, 2003, at 11:17 AM, Meyer, Jeffrey D (<A =
class=3Dmoz-txt-link-freetext =
href=3D"http://usage.fc.hp.c">http://usage.fc.hp.c</A>)
wrote:

    </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi,

  Again, I'd point out, that as Benoit indicates, there are likely to
be different things we want to send as "options".

  Rather than inventing an entirely new model, just make option a
flag on the template and REUSE what we already have for data records.
It's that simple!

-- Jeff

-----Original Message-----
From: majordomo listserver [<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wis=
c.edu</A>]On
Behalf
Of Benoit Claise
Sent: Monday, December 22, 2003 4:04 AM
To: Mark Fullmer
Cc: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:ipfix@net.doit.wisc.edu">ipfix@net.doit.wisc.edu</A>
Subject: Re: [ipfix] Option templates issues


Mark,

[sorry for the delay, i've been absent from the list for a while]

I understand the concern but let me ask a few questions.
What if the metering process can't "meter" one of them? Ex: flows not
exported due to resource starvation
What if we would like to export some extra data types? Ex: IPv6=20
packets
and bytes dropped
So what if the METERSTAT struct is slightly modified?

Ganesh had a good point I think:
    If the group can come up with fixed structs that you mentioned
below,
    then I think what you propose can be adopted.

Aren't we going to spend a long time to determine what MUST be=20
exported
in this/those structure(s)?
What you defined in your METERSTAT makes perfectly from a collector
point of view but will not always be possible to collect on the
exporter?
And it does perfectly sense now, but what about in 1 year? So would we
have a new data type with a new slightly different structure?

I'm just wondering what we should say in the protocol draft:
    1. SHOULD export a METERSTAT data type(as described in your=20
email)?
What if one data type can't be exported, we don't send any metering
stats "message"?
    2. MUST export a metering statistics Options Templates that SHOULD
contain lost_flows, lost_flows_pkts, lost_flows_bytes, lost_pkts,
lost_bytes, time.
    3. MUST export a metering statistics Options Templates that MUST
contain X, Y, and SHOULD contain Z
    4. MUST export a metering statistics Options Templates that=20
contain
at least X, Y

Actually, I think the flexibility of the Options Template is=20
benefitial
for any data types.

Now, this is a different story for the Hello, Failover, etc... types=20
of
messages that you spoke about, as the goal is totally different!

Regards, Benoit.

      </PRE>
        <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">I'd like to propose an =
alternative mechanism for sending auxiliary
data such
as time synch messages, protocol hellos (needed for fail-over),
metering
process loss statistics (ie packets/flows lost due to resource
starvation),
etc.

The existing framework allows "other" data to be sent in options
templates.
Take for example a metering process stat message.  Lets say the
metering
process will periodically report statistics such as

  struct METERSTAT {
    u_int32_t lost_flows;       /* flows not exported due to resource
starvation */
    u_int32_t lost_flows_pkts;  /* packets in the lost flows */
    u_int32_t lost_flows_bytes; /* bytes in the lost flows */
    u_int32_t lost_pkts;   /* packets dropped by metering process */
    u_int32_t lost_bytes;  /* bytes dropped by metering process */
    time_t    now;         /* when this record was generated */
  };

  The question becomes how to encode this with an options template.

  Each field in the record could have a type (6 types), then the
options template
  would list each of the 6 types.  The problem here is during
decoding.  What
  will the collector do if only 5 of these items show up.  The packet
decode
  process is also not very straightforward when just data is sent
(other option
  fields could be in the same template) because it will have to=20
figure
out
  what to do based on the field type and there's no way to group
fields.
        </PRE></BLOCKQUOTE>
        <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">  The other option is =
to call METERSTAT a type (of length 24).  Now
the
  decode process can key off of the type and all the fields will
always be
  there because METERSTAT is fixed and defined in the protocol
document just
  like other fields like PACKETS, BYTES, PROTOCOL, etc.  The issue I
have here
  is why are we bothering with a template/data model for this.  Why
not just
  use traditional TLV's.

  So what I'd like to see (I think) is to take one of the existing
reserved
  flowset ID's, lets say 3 and use it for generic TLV data encodings.
Then
  define structured data in the protocol such as METERSTAT.  IMHO=20
this
allows us
  to address a number of other issues including how to add HELLO's=20
for
the
  (optional) reliable failover, how to add aux flags like "this is
potentially
  a duplicate PDU because I failed over", etc.

  The TLV encodings would only be used for the low bit-rate protocol
messages,
  NOT the high bandwidth flow data.  I'm also not proposing the=20
option
templates
  go away, just that we use a more traditional method for encoding=20
the
non flow
  data.

mark



--=20
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say "help" in
message body
Unsubscribe <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/a=
rchive/</A>
        </PRE></BLOCKQUOTE><PRE wrap=3D"">

--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say "help" in
message body
Unsubscribe <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/a=
rchive/</A>

      </PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->

--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say "help" in message body
Unsubscribe <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/a=
rchive/</A>
  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3D703.EFB5394A--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sun Jan 11 20:53:35 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25853
	for <ipfix-archive@lists.ietf.org>; Sun, 11 Jan 2004 20:53:35 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Afqrj-0000VQ-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 11 Jan 2004 19:27:39 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1Afqri-0000VL-00
	for ipfix@net.doit.wisc.edu; Sun, 11 Jan 2004 19:27:38 -0600
Received: (qmail 1756 invoked by alias); 12 Jan 2004 01:27:36 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 12 Jan 2004 01:27:36 -0000
In-Reply-To: <A747B346BDCCAB45831C24F0CD7C7F09177D3F@cacexc03.americas.cpqcorp.net>
References: <A747B346BDCCAB45831C24F0CD7C7F09177D3F@cacexc03.americas.cpqcorp.net>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8070399F-449E-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Option templates issues
Date: Sun, 11 Jan 2004 20:27:35 -0500
To: "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

It's common for a router to send flow data to a proxy which will then
fan-out to multiple collectors.  For example one collector may be an IDS
while the other is used for billing.

This is why we need to explicitly send the exporter ID (IP address) 
inside
the IPFIX message.  Relying on the transport source IP address becomes
a problem when proxies are involved.  With NetFlow running over UDP you
could work around this problem with the proxy spoofing the source IP
address to the downstream collectors.  This work around is ugly and
problematic given current best practices drop spoofed sources.  It's not
even practical for IPFIX over TCP or SCTP.

We have a requirement for extensibility.  Tal (I believe) suggested that
reliable fail-over be at least specified to fulfill this requirement.

My concern is that trying to add this extension within the options 
framework
is more complicated than it should be and we need a more generic 
mechanism
for protocol extensions.

Another concern is we probably have field(s) in the fixed header that 
don't
belong there.  An example would be the current unix_secs.  NetFlow v9
omitted unix_nsecs from the header thus breaking sub-second timestamps
that were available in prior NetFlow versions.  This is a static header
field, which can't be changed without changing the protocol version thus
totally incompatible with existing deployments.  We need to be able to
add both information and protocol elements to IPFIX without breaking
collectors.

Slightly unrelated is another need for a HELLO or keep-alive.  Currently
there's no way for a collector to tell the difference between a broken
exporter configuration and a quiet exporter generating no data.  This
is less of an issue for TCP/SCTP transports which will eventually close
due to timeouts, but that's still usually on the order of hours for TCP.

A fixed option is really nothing more than a TLV....We have 3-255 to 
work
with.  If we require that ID's 3-255 all have a Length following the
template ID we can add new features without breaking existing 
collectors.

Just an example to clarify that TLV's are not a new encoding scheme and
already in use by IPFIX just with a different terminology:

>  8.3 Data FlowSet Format
>
>    The format of the Data FlowSet is as follows:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    FlowSet ID = Template ID   |          Length               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Record 1 - Field Value 1    |   Record 1 - Field Value 2    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Record 1 - Field Value 3    |             ...               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

FlowSetID == T
Length    == L
<rest>    == V

This holds true for all existing FlowSet definitions.

mark

On Jan 7, 2004, at 2:04 AM, Meyer, Jeffrey D (http://usage.fc.hp.c) 
wrote:

> Mark,
>
>   Not having seen requirements or discussion for "proxies", I'm having 
> a hard time conceptualizing this new requirement.
>
>   Since option template Id's and flow record template Id's are 
> currently dynamically determined, I guess what you are arguing is that 
> options should somehow be fixed.
>
>   Since a "hello" option has not even been defined to date, and your 
> use case seems to be centered around reliable failover, I think there 
> are a lot of tangled concerns going on here.  Could you elaborate a 
> bit more on this scenario?
>
> -- Jeff
>
> -----Original Message-----
> From: Mark Fullmer [mailto:maf@eng.oar.net]
> Sent: Tuesday, January 06, 2004 10:36 PM
> To: Meyer, Jeffrey D (http://usage.fc.hp.c)
> Cc: 'Ipfix Wg' (E-mail)
> Subject: Re: [ipfix] Option templates issues
>
>
> Consider a proxy.  If the proxy needs to use an option ID to say
> maintain
> HELLO's for a reliable fail-over mechanism it will have to pick a
> template ID
> that potentially clashes with a future one used by an exporter.  So now
> a proxy needs to track all inbound template ID's, map them to outbound
> ID's,
> and rewrite fields in the messages that refer to the template ID's.
>
> mark
>
> On Dec 23, 2003, at 2:12 PM, Meyer, Jeffrey D (http://usage.fc.hp.c)
> wrote:
>
>> Mark,
>>
>>   Agreed, it is a choice, and both will work, it is a questions of
>> anticipated extensibility.  Fewer fields in the header and most
>> information elements defined in a consistent manner seems to me to
>> address the approach of "Make it as simple as possible and no
>> simpler".
>>
>>   Since the requirement appears to be addressable with a single
>> mechanism, i.e. a flag distinguishing options from flow elements, and
>> reusing the information modeling, I still don't see the benefit in
>> introducing more mechanisms which need to be implemented and tested on
>> both ends.
>>
>> -- Jeff
>>
>> -----Original Message-----
>> From: Mark Fullmer [mailto:maf@eng.oar.net]
>> Sent: Tuesday, December 23, 2003 10:11 AM
>> To: Meyer, Jeffrey D (http://usage.fc.hp.c)
>> Cc: ipfix@net.doit.wisc.edu; Benoit Claise
>> Subject: Re: [ipfix] Option templates issues
>>
>>
>> There are two issues here
>>
>>    1) How to provide extra information about the flow data and 
>> metering
>>       process.
>>
>>    2) How to allow for protocol extensions.
>>
>> If we add a required "key" or "command" field to the options templates
>> then I think what we have will work given the proper text
>> describing what IE's MAY, SHOULD, and MUST be present in an options
>> template with a specific key.  We may want to even have a separate
>> IE namespace for the options....
>>
>> The protocol extension I'm still of the opinion should be handled
>> with an extensible header.  Examples of protocol extensions could be
>>
>>     Reliable fail-over.
>>
>>     Authentication.
>>
>>     The optional time stamp for the split-time model.
>>
>>     Hooks for proxies.
>>
>>     Future unanticipated extensions.
>>
>> And yes, all of this could be stuffed in an options template but the
>> same
>> argument could be used to do away with the protocol header entirely.
>>
>> mark
>>
>>
>> On Dec 22, 2003, at 11:17 AM, Meyer, Jeffrey D (http://usage.fc.hp.c)
>> wrote:
>>
>>> Hi,
>>>
>>>   Again, I'd point out, that as Benoit indicates, there are likely to
>>> be different things we want to send as "options".
>>>
>>>   Rather than inventing an entirely new model, just make option a
>>> flag on the template and REUSE what we already have for data records.
>>> It's that simple!
>>>
>>> -- Jeff
>>>
>>> -----Original Message-----
>>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
>>> Behalf
>>> Of Benoit Claise
>>> Sent: Monday, December 22, 2003 4:04 AM
>>> To: Mark Fullmer
>>> Cc: ipfix@net.doit.wisc.edu
>>> Subject: Re: [ipfix] Option templates issues
>>>
>>>
>>> Mark,
>>>
>>> [sorry for the delay, i've been absent from the list for a while]
>>>
>>> I understand the concern but let me ask a few questions.
>>> What if the metering process can't "meter" one of them? Ex: flows not
>>> exported due to resource starvation
>>> What if we would like to export some extra data types? Ex: IPv6
>>> packets
>>> and bytes dropped
>>> So what if the METERSTAT struct is slightly modified?
>>>
>>> Ganesh had a good point I think:
>>>     If the group can come up with fixed structs that you mentioned
>>> below,
>>>     then I think what you propose can be adopted.
>>>
>>> Aren't we going to spend a long time to determine what MUST be
>>> exported
>>> in this/those structure(s)?
>>> What you defined in your METERSTAT makes perfectly from a collector
>>> point of view but will not always be possible to collect on the
>>> exporter?
>>> And it does perfectly sense now, but what about in 1 year? So would 
>>> we
>>> have a new data type with a new slightly different structure?
>>>
>>> I'm just wondering what we should say in the protocol draft:
>>>     1. SHOULD export a METERSTAT data type(as described in your
>>> email)?
>>> What if one data type can't be exported, we don't send any metering
>>> stats "message"?
>>>     2. MUST export a metering statistics Options Templates that 
>>> SHOULD
>>> contain lost_flows, lost_flows_pkts, lost_flows_bytes, lost_pkts,
>>> lost_bytes, time.
>>>     3. MUST export a metering statistics Options Templates that MUST
>>> contain X, Y, and SHOULD contain Z
>>>     4. MUST export a metering statistics Options Templates that
>>> contain
>>> at least X, Y
>>>
>>> Actually, I think the flexibility of the Options Template is
>>> benefitial
>>> for any data types.
>>>
>>> Now, this is a different story for the Hello, Failover, etc... types
>>> of
>>> messages that you spoke about, as the goal is totally different!
>>>
>>> Regards, Benoit.
>>>
>>>>
>>>> I'd like to propose an alternative mechanism for sending auxiliary
>>>> data such
>>>> as time synch messages, protocol hellos (needed for fail-over),
>>>> metering
>>>> process loss statistics (ie packets/flows lost due to resource
>>>> starvation),
>>>> etc.
>>>>
>>>> The existing framework allows "other" data to be sent in options
>>>> templates.
>>>> Take for example a metering process stat message.  Lets say the
>>>> metering
>>>> process will periodically report statistics such as
>>>>
>>>>   struct METERSTAT {
>>>>     u_int32_t lost_flows;       /* flows not exported due to 
>>>> resource
>>>> starvation */
>>>>     u_int32_t lost_flows_pkts;  /* packets in the lost flows */
>>>>     u_int32_t lost_flows_bytes; /* bytes in the lost flows */
>>>>     u_int32_t lost_pkts;   /* packets dropped by metering process */
>>>>     u_int32_t lost_bytes;  /* bytes dropped by metering process */
>>>>     time_t    now;         /* when this record was generated */
>>>>   };
>>>>
>>>>   The question becomes how to encode this with an options template.
>>>>
>>>>   Each field in the record could have a type (6 types), then the
>>>> options template
>>>>   would list each of the 6 types.  The problem here is during
>>>> decoding.  What
>>>>   will the collector do if only 5 of these items show up.  The 
>>>> packet
>>>> decode
>>>>   process is also not very straightforward when just data is sent
>>>> (other option
>>>>   fields could be in the same template) because it will have to
>>>> figure
>>>> out
>>>>   what to do based on the field type and there's no way to group
>>>> fields.
>>>
>>>>
>>>>   The other option is to call METERSTAT a type (of length 24).  Now
>>>> the
>>>>   decode process can key off of the type and all the fields will
>>>> always be
>>>>   there because METERSTAT is fixed and defined in the protocol
>>>> document just
>>>>   like other fields like PACKETS, BYTES, PROTOCOL, etc.  The issue I
>>>> have here
>>>>   is why are we bothering with a template/data model for this.  Why
>>>> not just
>>>>   use traditional TLV's.
>>>>
>>>>   So what I'd like to see (I think) is to take one of the existing
>>>> reserved
>>>>   flowset ID's, lets say 3 and use it for generic TLV data 
>>>> encodings.
>>>> Then
>>>>   define structured data in the protocol such as METERSTAT.  IMHO
>>>> this
>>>> allows us
>>>>   to address a number of other issues including how to add HELLO's
>>>> for
>>>> the
>>>>   (optional) reliable failover, how to add aux flags like "this is
>>>> potentially
>>>>   a duplicate PDU because I failed over", etc.
>>>>
>>>>   The TLV encodings would only be used for the low bit-rate protocol
>>>> messages,
>>>>   NOT the high bandwidth flow data.  I'm also not proposing the
>>>> option
>>>> templates
>>>>   go away, just that we use a more traditional method for encoding
>>>> the
>>>> non flow
>>>>   data.
>>>>
>>>> mark
>>>>
>>>>
>>>>
>>>> -- 
>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>>>> message body
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>>
>>>
>>> --
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>>> message body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sun Jan 11 21:03:17 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26151
	for <ipfix-archive@lists.ietf.org>; Sun, 11 Jan 2004 21:03:17 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Afr3t-0000rD-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 11 Jan 2004 19:40:13 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1Afr3s-0000r5-00
	for ipfix@net.doit.wisc.edu; Sun, 11 Jan 2004 19:40:12 -0600
Received: (qmail 1815 invoked by alias); 12 Jan 2004 01:40:11 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 12 Jan 2004 01:40:11 -0000
Mime-Version: 1.0 (Apple Message framework v609)
Content-Transfer-Encoding: 7bit
Message-Id: <424B84EE-44A0-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
From: Mark Fullmer <maf@eng.oar.net>
Subject: [ipfix] Fwd: NetFlow v.x timestamp rollover
Date: Sun, 11 Jan 2004 20:40:10 -0500
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

<resending with a valid source address>

Begin forwarded message:

> From: Mark Fullmer <maf@splintered.net>
> Date: January 11, 2004 7:59:51 PM EST
> To: 'Ipfix Wg' (E-mail) <ipfix@net.doit.wisc.edu>
> Cc: Benoit Claise <bclaise@cisco.com>
> Subject: NetFlow v.x timestamp rollover
>
> Benoit asked for a clarification on the NetFlow vx timestamp rollover
> circumstance.
>
> Start and End time represent the router uptime in milliseconds.  This
> will rollover at 3^32-1 milliseconds or about every 49 days.  If a flow
> is created near this border the Start time will be greater then the
> End time.  For example
>
> Time  Event
> -------------------
> T1    router uptime is 4294967290 ms.
> T2    flow is created at sysUpTime of 4294967290.
> T3    flow is ended at sysUpTime of 4294967296 ms.
> T4    flow is expired at sysUpTime of 4294967297 ms.
>
> 4294967296 doesn't fit in 32 bits so the End time will be 0 due to
> rollover.  The header sysUptime will then be 1.
>
> If an application is using the header {sysUpTime,unix_secs,unix_nsecs) 
> to
> convert the flow {End,Start} time to real time it needs to be careful
> to take this rollover into consideration.
>
> Ditto for calculating flow durations.
>
> This situation does not happen in what we've been calling "split-time".
>
> --
> mark
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sun Jan 11 21:03:55 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26173
	for <ipfix-archive@lists.ietf.org>; Sun, 11 Jan 2004 21:03:54 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Afr55-0000s3-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 11 Jan 2004 19:41:27 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1Afr54-0000rx-00
	for ipfix@net.doit.wisc.edu; Sun, 11 Jan 2004 19:41:26 -0600
Received: (qmail 1824 invoked by alias); 12 Jan 2004 01:41:25 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 12 Jan 2004 01:41:25 -0000
In-Reply-To: <3FFD4AA8.7030402@cisco.com>
References: <A747B346BDCCAB45831C24F0CD7C7F09177D3F@cacexc03.americas.cpqcorp.net> <3FFD4AA8.7030402@cisco.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <6E219DD2-44A0-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: quoted-printable
Cc: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>,
        "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Option templates issues - Consensus?
Date: Sun, 11 Jan 2004 20:41:24 -0500
To: Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

Yes.

On Jan 8, 2004, at 7:18 AM, Benoit Claise wrote:

> Hi,
>
> In order to progress with the protocol draft... is there a consensus=20=

> for the following concepts?
>
> There are two issues here
>
> =A0 1) How to provide extra information about the flow data and =
metering
> =A0=A0=A0=A0 process.
>
> =A0 2) How to allow for protocol extensions.
>
> 1) How to provide extra information about the flow data and metering=20=

> process.
> Typical example: the meterstats.
> An option template will be used
> The protocol draft will specify what the minimal set of data types is=20=

> required
> A new data type (referred to ipfixOption by Jeff) would be used to=20
> identify specific options templates
> This would help the collector answering the question:
> switch (ipfixOption)
> =A0 case METER_STATS
> =A0=A0=A0 do that.
> =A0 case ...
> =A0=A0=A0 do something else.
>
> 2) How to allow for protocol extensions.
> Typical example: hello, exporter ID, authentication, etc...
> No options template: an extension to the header will be used.
>
> Regards, Benoit.
>
> Mark,
>
>   Not having seen requirements or discussion for "proxies", I'm having=20=

> a hard time conceptualizing this new requirement.
>
>   Since option template Id's and flow record template Id's are=20
> currently dynamically determined, I guess what you are arguing is that=20=

> options should somehow be fixed.
>
>   Since a "hello" option has not even been defined to date, and your=20=

> use case seems to be centered around reliable failover, I think there=20=

> are a lot of tangled concerns going on here.  Could you elaborate a=20
> bit more on this scenario?
>
> -- Jeff
>
> -----Original Message-----
> From: Mark Fullmer [mailto:maf@eng.oar.net]
> Sent: Tuesday, January 06, 2004 10:36 PM
> To: Meyer, Jeffrey D (http://usage.fc.hp.c)
> Cc: 'Ipfix Wg' (E-mail)
> Subject: Re: [ipfix] Option templates issues
>
>
> Consider a proxy.  If the proxy needs to use an option ID to say
> maintain
> HELLO's for a reliable fail-over mechanism it will have to pick a
> template ID
> that potentially clashes with a future one used by an exporter.  So =
now
> a proxy needs to track all inbound template ID's, map them to outbound
> ID's,
> and rewrite fields in the messages that refer to the template ID's.
>
> mark
>
> On Dec 23, 2003, at 2:12 PM, Meyer, Jeffrey D (http://usage.fc.hp.c)
> wrote:
>
>
> Mark,
>
>   Agreed, it is a choice, and both will work, it is a questions of
> anticipated extensibility.  Fewer fields in the header and most
> information elements defined in a consistent manner seems to me to
> address the approach of "Make it as simple as possible and no
> simpler".
>
>   Since the requirement appears to be addressable with a single
> mechanism, i.e. a flag distinguishing options from flow elements, and
> reusing the information modeling, I still don't see the benefit in
> introducing more mechanisms which need to be implemented and tested on
> both ends.
>
> -- Jeff
>
> -----Original Message-----
> From: Mark Fullmer [mailto:maf@eng.oar.net]
> Sent: Tuesday, December 23, 2003 10:11 AM
> To: Meyer, Jeffrey D (http://usage.fc.hp.c)
> Cc: ipfix@net.doit.wisc.edu; Benoit Claise
> Subject: Re: [ipfix] Option templates issues
>
>
> There are two issues here
>
>    1) How to provide extra information about the flow data and =
metering
>       process.
>
>    2) How to allow for protocol extensions.
>
> If we add a required "key" or "command" field to the options templates
> then I think what we have will work given the proper text
> describing what IE's MAY, SHOULD, and MUST be present in an options
> template with a specific key.  We may want to even have a separate
> IE namespace for the options....
>
> The protocol extension I'm still of the opinion should be handled
> with an extensible header.  Examples of protocol extensions could be
>
>     Reliable fail-over.
>
>     Authentication.
>
>     The optional time stamp for the split-time model.
>
>     Hooks for proxies.
>
>     Future unanticipated extensions.
>
> And yes, all of this could be stuffed in an options template but the
> same
> argument could be used to do away with the protocol header entirely.
>
> mark
>
>
> On Dec 22, 2003, at 11:17 AM, Meyer, Jeffrey D (http://usage.fc.hp.c)
> wrote:
>
>
> Hi,
>
>   Again, I'd point out, that as Benoit indicates, there are likely to
> be different things we want to send as "options".
>
>   Rather than inventing an entirely new model, just make option a
> flag on the template and REUSE what we already have for data records.
> It's that simple!
>
> -- Jeff
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
> Behalf
> Of Benoit Claise
> Sent: Monday, December 22, 2003 4:04 AM
> To: Mark Fullmer
> Cc: ipfix@net.doit.wisc.edu
> Subject: Re: [ipfix] Option templates issues
>
>
> Mark,
>
> [sorry for the delay, i've been absent from the list for a while]
>
> I understand the concern but let me ask a few questions.
> What if the metering process can't "meter" one of them? Ex: flows not
> exported due to resource starvation
> What if we would like to export some extra data types? Ex: IPv6
> packets
> and bytes dropped
> So what if the METERSTAT struct is slightly modified?
>
> Ganesh had a good point I think:
>     If the group can come up with fixed structs that you mentioned
> below,
>     then I think what you propose can be adopted.
>
> Aren't we going to spend a long time to determine what MUST be
> exported
> in this/those structure(s)?
> What you defined in your METERSTAT makes perfectly from a collector
> point of view but will not always be possible to collect on the
> exporter?
> And it does perfectly sense now, but what about in 1 year? So would we
> have a new data type with a new slightly different structure?
>
> I'm just wondering what we should say in the protocol draft:
>     1. SHOULD export a METERSTAT data type(as described in your
> email)?
> What if one data type can't be exported, we don't send any metering
> stats "message"?
>     2. MUST export a metering statistics Options Templates that SHOULD
> contain lost_flows, lost_flows_pkts, lost_flows_bytes, lost_pkts,
> lost_bytes, time.
>     3. MUST export a metering statistics Options Templates that MUST
> contain X, Y, and SHOULD contain Z
>     4. MUST export a metering statistics Options Templates that
> contain
> at least X, Y
>
> Actually, I think the flexibility of the Options Template is
> benefitial
> for any data types.
>
> Now, this is a different story for the Hello, Failover, etc... types
> of
> messages that you spoke about, as the goal is totally different!
>
> Regards, Benoit.
>
>
> I'd like to propose an alternative mechanism for sending auxiliary
> data such
> as time synch messages, protocol hellos (needed for fail-over),
> metering
> process loss statistics (ie packets/flows lost due to resource
> starvation),
> etc.
>
> The existing framework allows "other" data to be sent in options
> templates.
> Take for example a metering process stat message.  Lets say the
> metering
> process will periodically report statistics such as
>
>   struct METERSTAT {
>     u_int32_t lost_flows;       /* flows not exported due to resource
> starvation */
>     u_int32_t lost_flows_pkts;  /* packets in the lost flows */
>     u_int32_t lost_flows_bytes; /* bytes in the lost flows */
>     u_int32_t lost_pkts;   /* packets dropped by metering process */
>     u_int32_t lost_bytes;  /* bytes dropped by metering process */
>     time_t    now;         /* when this record was generated */
>   };
>
>   The question becomes how to encode this with an options template.
>
>   Each field in the record could have a type (6 types), then the
> options template
>   would list each of the 6 types.  The problem here is during
> decoding.  What
>   will the collector do if only 5 of these items show up.  The packet
> decode
>   process is also not very straightforward when just data is sent
> (other option
>   fields could be in the same template) because it will have to
> figure
> out
>   what to do based on the field type and there's no way to group
> fields.
>
>   The other option is to call METERSTAT a type (of length 24).  Now
> the
>   decode process can key off of the type and all the fields will
> always be
>   there because METERSTAT is fixed and defined in the protocol
> document just
>   like other fields like PACKETS, BYTES, PROTOCOL, etc.  The issue I
> have here
>   is why are we bothering with a template/data model for this.  Why
> not just
>   use traditional TLV's.
>
>   So what I'd like to see (I think) is to take one of the existing
> reserved
>   flowset ID's, lets say 3 and use it for generic TLV data encodings.
> Then
>   define structured data in the protocol such as METERSTAT.  IMHO
> this
> allows us
>   to address a number of other issues including how to add HELLO's
> for
> the
>   (optional) reliable failover, how to add aux flags like "this is
> potentially
>   a duplicate PDU because I failed over", etc.
>
>   The TLV encodings would only be used for the low bit-rate protocol
> messages,
>   NOT the high bandwidth flow data.  I'm also not proposing the
> option
> templates
>   go away, just that we use a more traditional method for encoding
> the
> non flow
>   data.
>
> mark
>
>
>
> --=20
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
> =20=


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sun Jan 11 21:10:17 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26294
	for <ipfix-archive@lists.ietf.org>; Sun, 11 Jan 2004 21:10:17 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AfrAk-0000wB-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 11 Jan 2004 19:47:18 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AfrAj-0000w1-00
	for ipfix@net.doit.wisc.edu; Sun, 11 Jan 2004 19:47:17 -0600
Received: (qmail 1839 invoked by alias); 12 Jan 2004 01:47:15 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 12 Jan 2004 01:47:15 -0000
In-Reply-To: <A747B346BDCCAB45831C24F0CD7C7F09177D68@cacexc03.americas.cpqcorp.net>
References: <A747B346BDCCAB45831C24F0CD7C7F09177D68@cacexc03.americas.cpqcorp.net>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <3F1ADFD2-44A1-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: quoted-printable
Cc: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>,
        "Benoit Claise" <bclaise@cisco.com>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Option templates issues - Consensus?
Date: Sun, 11 Jan 2004 20:47:14 -0500
To: "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

I think that's where we're at.  Ganesh had suggested the extensible=20
header
idea after my proposal for using one of the unused FlowSet ID's.

Benoit have discussed this offline and (I think) we're both leaning=20
towards
using the existing mechanism with FlowSet ID's.  The only real change
this may mean for IPFIX is a better term than "FlowSet".

mark

On Jan 9, 2004, at 5:57 PM, Meyer, Jeffrey D (http://usage.fc.hp.c)=20
wrote:

> =A0 The mechanism for adding extensions would seem to be based on the=20=

> reserved range of 0-255 for templateId's.=A0 Currently 0 and 1
> =A0 are used for flow templates and option templates.=A0 Flow data and=20=

> option data are distinguished solely based on previous id assignments
> =A0 by the respective templates.
> =A0
> =A0 So I guess the proposal would be a hello message or other header=20=

> extensions would utilize other values in the range 2-255.=A0 Is this
> =A0 correct?
> =A0
> Regards,
> =A0
> =A0 Jeff Meyer
> -----Original Message-----
> From:Benoit Claise [mailto:bclaise@cisco.com]
> Sent:Thursday, January 08, 2004 4:19 AM
> To:Meyer, Jeffrey D (http://usage.fc.hp.c)
> Cc:Mark Fullmer; 'Ipfix Wg' (E-mail)
> Subject:Re: [ipfix] Option templates issues - Consensus?
>
> Hi,
>
> In order to progress with the protocol draft... is there a consensus=20=

> for the following concepts?
>
> There are two issues here
>
> =A0 1) How to provide extra information about the flow data and =
metering
> =A0=A0=A0=A0 process.
>
> =A0 2) How to allow for protocol extensions.
>
> 1) How to provide extra information about the flow data and metering=20=

> process.
> Typical example: the meterstats.
> An option template will be used
> The protocol draft will specify what the minimal set of data types is=20=

> required
> A new data type (referred to ipfixOption by Jeff) would be used to=20
> identify specific options templates
> This would help the collector answering the question:
> switch (ipfixOption)
> =A0 case METER_STATS
> =A0=A0=A0 do that.
> =A0 case ...
> =A0=A0=A0 do something else.
>
> 2) How to allow for protocol extensions.
> Typical example: hello, exporter ID, authentication, etc...
> No options template: an extension to the header will be used.
>
> Regards, Benoit.
>
> Mark,
>
>   Not having seen requirements or discussion for "proxies", I'm having=20=

> a hard time conceptualizing this new requirement.
>
>   Since option template Id's and flow record template Id's are=20
> currently dynamically determined, I guess what you are arguing is that=20=

> options should somehow be fixed.
>
>   Since a "hello" option has not even been defined to date, and your=20=

> use case seems to be centered around reliable failover, I think there=20=

> are a lot of tangled concerns going on here.  Could you elaborate a=20
> bit more on this scenario?
>
> -- Jeff
>
> -----Original Message-----
> From: Mark Fullmer [mailto:maf@eng.oar.net]
> Sent: Tuesday, January 06, 2004 10:36 PM
> To: Meyer, Jeffrey D (http://usage.fc.hp.c)
> Cc: 'Ipfix Wg' (E-mail)
> Subject: Re: [ipfix] Option templates issues
>
>
> Consider a proxy.  If the proxy needs to use an option ID to say
> maintain
> HELLO's for a reliable fail-over mechanism it will have to pick a
> template ID
> that potentially clashes with a future one used by an exporter.  So =
now
> a proxy needs to track all inbound template ID's, map them to outbound
> ID's,
> and rewrite fields in the messages that refer to the template ID's.
>
> mark
>
> On Dec 23, 2003, at 2:12 PM, Meyer, Jeffrey D (http://usage.fc.hp.c)
> wrote:
>
>
> Mark,
>
>   Agreed, it is a choice, and both will work, it is a questions of
> anticipated extensibility.  Fewer fields in the header and most
> information elements defined in a consistent manner seems to me to
> address the approach of "Make it as simple as possible and no
> simpler".
>
>   Since the requirement appears to be addressable with a single
> mechanism, i.e. a flag distinguishing options from flow elements, and
> reusing the information modeling, I still don't see the benefit in
> introducing more mechanisms which need to be implemented and tested on
> both ends.
>
> -- Jeff
>
> -----Original Message-----
> From: Mark Fullmer [mailto:maf@eng.oar.net]
> Sent: Tuesday, December 23, 2003 10:11 AM
> To: Meyer, Jeffrey D (http://usage.fc.hp.c)
> Cc: ipfix@net.doit.wisc.edu; Benoit Claise
> Subject: Re: [ipfix] Option templates issues
>
>
> There are two issues here
>
>    1) How to provide extra information about the flow data and =
metering
>       process.
>
>    2) How to allow for protocol extensions.
>
> If we add a required "key" or "command" field to the options templates
> then I think what we have will work given the proper text
> describing what IE's MAY, SHOULD, and MUST be present in an options
> template with a specific key.  We may want to even have a separate
> IE namespace for the options....
>
> The protocol extension I'm still of the opinion should be handled
> with an extensible header.  Examples of protocol extensions could be
>
>     Reliable fail-over.
>
>     Authentication.
>
>     The optional time stamp for the split-time model.
>
>     Hooks for proxies.
>
>     Future unanticipated extensions.
>
> And yes, all of this could be stuffed in an options template but the
> same
> argument could be used to do away with the protocol header entirely.
>
> mark
>
>
> On Dec 22, 2003, at 11:17 AM, Meyer, Jeffrey D (http://usage.fc.hp.c)
> wrote:
>
>
> Hi,
>
>   Again, I'd point out, that as Benoit indicates, there are likely to
> be different things we want to send as "options".
>
>   Rather than inventing an entirely new model, just make option a
> flag on the template and REUSE what we already have for data records.
> It's that simple!
>
> -- Jeff
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
> Behalf
> Of Benoit Claise
> Sent: Monday, December 22, 2003 4:04 AM
> To: Mark Fullmer
> Cc: ipfix@net.doit.wisc.edu
> Subject: Re: [ipfix] Option templates issues
>
>
> Mark,
>
> [sorry for the delay, i've been absent from the list for a while]
>
> I understand the concern but let me ask a few questions.
> What if the metering process can't "meter" one of them? Ex: flows not
> exported due to resource starvation
> What if we would like to export some extra data types? Ex: IPv6
> packets
> and bytes dropped
> So what if the METERSTAT struct is slightly modified?
>
> Ganesh had a good point I think:
>     If the group can come up with fixed structs that you mentioned
> below,
>     then I think what you propose can be adopted.
>
> Aren't we going to spend a long time to determine what MUST be
> exported
> in this/those structure(s)?
> What you defined in your METERSTAT makes perfectly from a collector
> point of view but will not always be possible to collect on the
> exporter?
> And it does perfectly sense now, but what about in 1 year? So would we
> have a new data type with a new slightly different structure?
>
> I'm just wondering what we should say in the protocol draft:
>     1. SHOULD export a METERSTAT data type(as described in your
> email)?
> What if one data type can't be exported, we don't send any metering
> stats "message"?
>     2. MUST export a metering statistics Options Templates that SHOULD
> contain lost_flows, lost_flows_pkts, lost_flows_bytes, lost_pkts,
> lost_bytes, time.
>     3. MUST export a metering statistics Options Templates that MUST
> contain X, Y, and SHOULD contain Z
>     4. MUST export a metering statistics Options Templates that
> contain
> at least X, Y
>
> Actually, I think the flexibility of the Options Template is
> benefitial
> for any data types.
>
> Now, this is a different story for the Hello, Failover, etc... types
> of
> messages that you spoke about, as the goal is totally different!
>
> Regards, Benoit.
>
>
> I'd like to propose an alternative mechanism for sending auxiliary
> data such
> as time synch messages, protocol hellos (needed for fail-over),
> metering
> process loss statistics (ie packets/flows lost due to resource
> starvation),
> etc.
>
> The existing framework allows "other" data to be sent in options
> templates.
> Take for example a metering process stat message.  Lets say the
> metering
> process will periodically report statistics such as
>
>   struct METERSTAT {
>     u_int32_t lost_flows;       /* flows not exported due to resource
> starvation */
>     u_int32_t lost_flows_pkts;  /* packets in the lost flows */
>     u_int32_t lost_flows_bytes; /* bytes in the lost flows */
>     u_int32_t lost_pkts;   /* packets dropped by metering process */
>     u_int32_t lost_bytes;  /* bytes dropped by metering process */
>     time_t    now;         /* when this record was generated */
>   };
>
>   The question becomes how to encode this with an options template.
>
>   Each field in the record could have a type (6 types), then the
> options template
>   would list each of the 6 types.  The problem here is during
> decoding.  What
>   will the collector do if only 5 of these items show up.  The packet
> decode
>   process is also not very straightforward when just data is sent
> (other option
>   fields could be in the same template) because it will have to
> figure
> out
>   what to do based on the field type and there's no way to group
> fields.
>
>   The other option is to call METERSTAT a type (of length 24).  Now
> the
>   decode process can key off of the type and all the fields will
> always be
>   there because METERSTAT is fixed and defined in the protocol
> document just
>   like other fields like PACKETS, BYTES, PROTOCOL, etc.  The issue I
> have here
>   is why are we bothering with a template/data model for this.  Why
> not just
>   use traditional TLV's.
>
>   So what I'd like to see (I think) is to take one of the existing
> reserved
>   flowset ID's, lets say 3 and use it for generic TLV data encodings.
> Then
>   define structured data in the protocol such as METERSTAT.  IMHO
> this
> allows us
>   to address a number of other issues including how to add HELLO's
> for
> the
>   (optional) reliable failover, how to add aux flags like "this is
> potentially
>   a duplicate PDU because I failed over", etc.
>
>   The TLV encodings would only be used for the low bit-rate protocol
> messages,
>   NOT the high bandwidth flow data.  I'm also not proposing the
> option
> templates
>   go away, just that we use a more traditional method for encoding
> the
> non flow
>   data.
>
> mark
>
>
>
> --=20
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in=20
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sun Jan 11 22:49:32 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28361
	for <ipfix-archive@lists.ietf.org>; Sun, 11 Jan 2004 22:49:32 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AfswH-000429-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 11 Jan 2004 21:40:29 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AfswG-000424-00
	for ipfix@net.doit.wisc.edu; Sun, 11 Jan 2004 21:40:28 -0600
Received: (qmail 2318 invoked by alias); 12 Jan 2004 03:40:27 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 12 Jan 2004 03:40:27 -0000
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0F408853-44B1-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: Benoit Claise <bclaise@cisco.com>
From: Mark Fullmer <maf@eng.oar.net>
Subject: [ipfix] protocol security section
Date: Sun, 11 Jan 2004 22:40:26 -0500
To: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

This is a rough draft of a security section.  I'd like to be able to
enumerate the attack scenarios better but this requires we get the
UDP/no UDP directive and relating issues behind us.  I think at least
all the issues are here.

I'm also leaning towards a simple authentication (plain text password
for example) option available in the protocol so that a collector can
at least have some idea who its talking to without requiring IPSec.

---

The IPFIX protocol provides no means to secure messages between the
exporter and collector, or a mechanism to provide for mutual
authentication.  IPSec MAY be used for message authentication and or
encryption, but this may not address all the security issues present
in an IPFIX deployment.

Some IPFIX security issues are dependent on the transport.  For example
with UDP unsolicited messages may be received and not detected, with
a modern implementation of TCP with good ISN randomization 
[XXX-REFERENCE]
or SCTP these types of attacks are much more difficult without an 
attacker
with access to snoop the packet flow. 
[XXX-SCTP-BLIND-SPOOFING-REFERENCE]

IPFIX has a sequence number which increases with each message.  A
collector may detect out of sequence, dropped, or duplicate messages
by tracking the sequence number.  A collector SHOULD provide a logging
mechanism for tracking out of sequence messages.  Such out of sequence
messages may be due to congestion on the network link between the
exporter and collector, collector resource exhaustion where it can not
process the messages at their arrival rate, exporter resource exhaustion
where it can not transmit messages at their creation rate, out of order
packet reception, duplicate packet reception, an exportering process 
reset,
or an attacker injecting false messages.

An attacker may be in a position to inject false messages into an IPFIX
message stream.  This type of attack may require the ability to sniff
packets on the network segment connecting the exporter and collector, or
in the case of UDP knowing the collector IP address and port the IPFIX
process is bound to may be sufficient.  Injecting false messages will 
allow
the attacker to send forged flow records, options, or templates.  Forged
templates may impair the collectors ability to process any further flow
records.  Forged flow records would have a direct effect on the 
application
using the flows, for example a billing system may generate incorrect 
billing
information.  Forged options may be able to alter the meaning of flow 
records,
for example if the sample rate is changed.

Packet flooding or other Denial of Service techniques may be used to 
cripple
the collectors ability to receive and/or process incoming IPFIX 
messages.

A collector has no means to authenticate an exporter other than the
exporters Source IP address.  It is common for a single exporter to
process flow records for multiple collectors, and therefore the 
collector
administrator may not impose source IP address restrictions, leaving
the collector open to reception of invalid flows.

Another type of attack involves using an IPFIX exporter to amplify
packet flows.  For example one 40 byte IP datagram may generate
a single 48 byte flow.  When this IP datagram transverses multiple
routers exporting flows its impact on the network may be amplified
depending on the location of the collector(s).

For exmple if an attacker (A) sends 1000 40 byte packets to destination
(D) which each generate one flow and R1..R4 are configured to export
flows to C, the link to C will experience at least 4x the traffic the
attacker is generating.  The link from R2 to R3 would need to carry both
the outbound attack and the IPFIX messages from R4 and R3.

       R1-----R2------R3------R4
       |       |              |
       A       C              D

--
mark


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 12 00:33:39 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01182
	for <ipfix-archive@lists.ietf.org>; Mon, 12 Jan 2004 00:33:39 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AfuYz-0006l1-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 11 Jan 2004 23:24:33 -0600
Received: from bay3-f10.bay3.hotmail.com ([65.54.169.10] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AfuYy-0006kw-00
	for ipfix@net.doit.wisc.edu; Sun, 11 Jan 2004 23:24:32 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 11 Jan 2004 21:24:32 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Mon, 12 Jan 2004 05:24:31 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] New E-mail Address for Jeff Meyer
Date: Sun, 11 Jan 2004 21:24:31 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F10FKGEFDFWTWH00002802@hotmail.com>
X-OriginalArrivalTime: 12 Jan 2004 05:24:32.0010 (UTC) FILETIME=[5BB62EA0:01C3D8CC]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Hi,

  I am no longer accessing mail sent to jeff.meyer2@hp.com.  If you are 
sending any non-group messages to me, please use my new e-mail:  
inetpix@msn.com.

  I intend to continue as one of the co-editor for the IPFIX Information 
Model as an individual contributor.

  You might want to resend any e-mail adressed to my old address (if any) 
between ~noon Friday January 9, 2004 and late Sunday Jan. 11 2004.

Regards,

  Jeff Meyer

_________________________________________________________________
Let the new MSN Premium Internet Software make the most of your high-speed 
experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 12 06:03:34 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21806
	for <ipfix-archive@lists.ietf.org>; Mon, 12 Jan 2004 06:03:33 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AfzSV-0000eU-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jan 2004 04:38:11 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AfzSU-0000eN-00
	for ipfix@net.doit.wisc.edu; Mon, 12 Jan 2004 04:38:10 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 12 Jan 2004 11:38:55 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i0CAbnHJ016588;
	Mon, 12 Jan 2004 11:37:49 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp4327.cisco.com [10.61.80.230])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA29651;
	Mon, 12 Jan 2004 10:38:06 GMT
Message-ID: <4002790B.4020607@cisco.com>
Date: Mon, 12 Jan 2004 10:38:03 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>,
        Benoit Claise <bclaise@cisco.com>
Subject: Re: [ipfix] protocol security section
References: <0F408853-44B1-11D8-BCCB-000A95DA1C38@eng.oar.net>
In-Reply-To: <0F408853-44B1-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Mark

I have some worries about this section.

IPFIX is just another application that runs over IP
via an IETF defined transport, and as such it should
punt the issues to an IETF common solution. That
solution is IPsec, and if IPsec is inadequate the
matter should be addressed by the IPsec WG.

The standard response to that is that IPsec is too
heavyweight, but again we should be looking for a
common solution rather than a roll-your-own for each
application that needs security, but feels that IPsec
is too heavyweight.

I have some more comments in-line.


Mark Fullmer wrote:
> This is a rough draft of a security section.  I'd like to be able to
> enumerate the attack scenarios better but this requires we get the
> UDP/no UDP directive and relating issues behind us.  I think at least
> all the issues are here.
> 
> I'm also leaning towards a simple authentication (plain text password
> for example) option available in the protocol so that a collector can
> at least have some idea who its talking to without requiring IPSec.
> 

In <draft-ietf-l2tpext-l2tp-base-11.txt> which also has issues with
IPsec being too heavy weight, it is proposed that blind insertion
attacks be addressed through the use of a 64 bit cookie (a 64 bit
randomly chosen password common to each end) is used. I am not sure
whether this is going to be blessed by the IESG, but it would make
sense is we used exactly the same approach and exactly the same
argument (ie import their data plane security text). That way
either both get accepted, or a common work item addresses the shortfall.

Of course another solution to this is to call up L2TPv3 as a lightweight
transport protocol with counter insertion protection.

> ---
> 
> The IPFIX protocol provides no means to secure messages between the
> exporter and collector, or a mechanism to provide for mutual
> authentication.  IPSec MAY be used for message authentication and or
> encryption, but this may not address all the security issues present
> in an IPFIX deployment.


An alternative wording is something of the form:

The IPFIX is an application that can be run over a number of IETF defined
transport protocols. It introduces no new risks to the network and
is subject exactly the same risks of attack as any other application.

> 
> Some IPFIX security issues are dependent on the transport.  For example
> with UDP unsolicited messages may be received and not detected, with
> a modern implementation of TCP with good ISN randomization [XXX-REFERENCE]
> or SCTP these types of attacks are much more difficult without an attacker
> with access to snoop the packet flow. [XXX-SCTP-BLIND-SPOOFING-REFERENCE]
> 

But these are just the standard UDP risks.

> IPFIX has a sequence number which increases with each message.  A
> collector may detect out of sequence, dropped, or duplicate messages
> by tracking the sequence number.  A collector SHOULD provide a logging
> mechanism for tracking out of sequence messages.  Such out of sequence
> messages may be due to congestion on the network link between the
> exporter and collector, collector resource exhaustion where it can not
> process the messages at their arrival rate, exporter resource exhaustion
> where it can not transmit messages at their creation rate, out of order
> packet reception, duplicate packet reception, an exportering process reset,
> or an attacker injecting false messages.
> 
> An attacker may be in a position to inject false messages into an IPFIX
> message stream.  This type of attack may require the ability to sniff
> packets on the network segment connecting the exporter and collector, or
> in the case of UDP knowing the collector IP address and port the IPFIX
> process is bound to may be sufficient.  Injecting false messages will allow
> the attacker to send forged flow records, options, or templates.  

So this is where an L2TPv3 style cookie would help.

> Forged
> templates may impair the collectors ability to process any further flow
> records.  Forged flow records would have a direct effect on the application
> using the flows, for example a billing system may generate incorrect 
> billing
> information.  Forged options may be able to alter the meaning of flow 
> records,
> for example if the sample rate is changed.

We only send a small number of templates, but there are the most vulnerable
part of the system. Perhaps we should using IPsec to secure the templates
even in instances when we cannot afford to secure the flow records.

> 
> Packet flooding or other Denial of Service techniques may be used to 
> cripple
> the collectors ability to receive and/or process incoming IPFIX messages.
> 

Isn't this just standard?

> A collector has no means to authenticate an exporter other than the
> exporters Source IP address.  It is common for a single exporter to
> process flow records for multiple collectors, and therefore the collector
> administrator may not impose source IP address restrictions, leaving
> the collector open to reception of invalid flows.
> 

Don't you mean single collector multi-exporter?

> Another type of attack involves using an IPFIX exporter to amplify
> packet flows.  For example one 40 byte IP datagram may generate
> a single 48 byte flow.  When this IP datagram transverses multiple
> routers exporting flows its impact on the network may be amplified
> depending on the location of the collector(s).
> 
> For exmple if an attacker (A) sends 1000 40 byte packets to destination
> (D) which each generate one flow and R1..R4 are configured to export
> flows to C, the link to C will experience at least 4x the traffic the
> attacker is generating.  The link from R2 to R3 would need to carry both
> the outbound attack and the IPFIX messages from R4 and R3.
> 
>       R1-----R2------R3------R4
>       |       |              |
>       A       C              D
> 

We need to include some text addressing this. The solutions that
I can see are either a congestion aware IPFIX transport or a separate
collector network. But the former has its own risks:

There is a further risk that is not covered in this section. An attacker
can force the IPFIX transport into congestion discard as a cover for
their own activities. This is an interesting risk, because the IESG
insistence that we must use a congestion aware transport creates
a risk that IPFIX might be blinded to certain types of attack.

- Stewart


> -- 
> mark
> 
> 
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 12 06:56:52 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22944
	for <ipfix-archive@lists.ietf.org>; Mon, 12 Jan 2004 06:56:52 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Ag0J9-0002lE-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jan 2004 05:32:35 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Ag0J8-0002l9-00
	for ipfix@net.doit.wisc.edu; Mon, 12 Jan 2004 05:32:34 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 12 Jan 2004 12:33:20 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i0CBWDLv003128;
	Mon, 12 Jan 2004 12:32:13 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp4327.cisco.com [10.61.80.230])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA02790;
	Mon, 12 Jan 2004 11:32:31 GMT
Message-ID: <400285CB.6090500@cisco.com>
Date: Mon, 12 Jan 2004 11:32:27 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Option templates issues
References: <A747B346BDCCAB45831C24F0CD7C7F09177D3F@cacexc03.americas.cpqcorp.net> <8070399F-449E-11D8-BCCB-000A95DA1C38@eng.oar.net>
In-Reply-To: <8070399F-449E-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Mark Fullmer wrote:

> It's common for a router to send flow data to a proxy which will then
> fan-out to multiple collectors.  For example one collector may be an IDS
> while the other is used for billing.
> 
> This is why we need to explicitly send the exporter ID (IP address) inside
> the IPFIX message.  
 >
> Relying on the transport source IP address becomes
> a problem when proxies are involved.  With NetFlow running over UDP you
> could work around this problem with the proxy spoofing the source IP
> address to the downstream collectors.  This work around is ugly and
> problematic given current best practices drop spoofed sources.  It's not
> even practical for IPFIX over TCP or SCTP.

Will we ever need to run IPFIX though a NAT? ie, can we reply on the
IP address to be globally unique? If so we only need to worry
about the v4/v6 issues with including it in the IPFIX message.
If not then perhaps we need to use a real UID rather than IP address
plus local ID.

> 
> We have a requirement for extensibility.  Tal (I believe) suggested that
> reliable fail-over be at least specified to fulfill this requirement.
> 
> My concern is that trying to add this extension within the options 
> framework
> is more complicated than it should be and we need a more generic mechanism
> for protocol extensions.
> 
> Another concern is we probably have field(s) in the fixed header that don't
> belong there.  An example would be the current unix_secs.  NetFlow v9
> omitted unix_nsecs from the header thus breaking sub-second timestamps
> that were available in prior NetFlow versions.  This is a static header
> field, which can't be changed without changing the protocol version thus
> totally incompatible with existing deployments.  We need to be able to
> add both information and protocol elements to IPFIX without breaking
> collectors.

Mark is right, the whole system would be much more flexible if we stripped
the fixed header down to just the version and length, and then encoded the
rest as a flowset.

> 
> Slightly unrelated is another need for a HELLO or keep-alive.  Currently
> there's no way for a collector to tell the difference between a broken
> exporter configuration and a quiet exporter generating no data.  This
> is less of an issue for TCP/SCTP transports which will eventually close
> due to timeouts, but that's still usually on the order of hours for TCP.
> 

Won't we see templates from time to time?

> A fixed option is really nothing more than a TLV....We have 3-255 to work
> with.  If we require that ID's 3-255 all have a Length following the
> template ID we can add new features without breaking existing collectors.
> 
> Just an example to clarify that TLV's are not a new encoding scheme and
> already in use by IPFIX just with a different terminology:
> 
>>  8.3 Data FlowSet Format
>>
>>    The format of the Data FlowSet is as follows:
>>
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |    FlowSet ID = Template ID   |          Length               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |   Record 1 - Field Value 1    |   Record 1 - Field Value 2    |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |   Record 1 - Field Value 3    |             ...               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> FlowSetID == T
> Length    == L
> <rest>    == V
> 
> This holds true for all existing FlowSet definitions.
> 
> mark
> 
> On Jan 7, 2004, at 2:04 AM, Meyer, Jeffrey D (http://usage.fc.hp.c) wrote:
> 
>> Mark,
>>
>>   Not having seen requirements or discussion for "proxies", I'm having 
>> a hard time conceptualizing this new requirement.
>>
>>   Since option template Id's and flow record template Id's are 
>> currently dynamically determined, I guess what you are arguing is that 
>> options should somehow be fixed.
>>
>>   Since a "hello" option has not even been defined to date, and your 
>> use case seems to be centered around reliable failover, I think there 
>> are a lot of tangled concerns going on here.  Could you elaborate a 
>> bit more on this scenario?
>>
>> -- Jeff
>>
>> -----Original Message-----
>> From: Mark Fullmer [mailto:maf@eng.oar.net]
>> Sent: Tuesday, January 06, 2004 10:36 PM
>> To: Meyer, Jeffrey D (http://usage.fc.hp.c)
>> Cc: 'Ipfix Wg' (E-mail)
>> Subject: Re: [ipfix] Option templates issues
>>
>>
>> Consider a proxy.  If the proxy needs to use an option ID to say
>> maintain
>> HELLO's for a reliable fail-over mechanism it will have to pick a
>> template ID
>> that potentially clashes with a future one used by an exporter.  So now
>> a proxy needs to track all inbound template ID's, map them to outbound
>> ID's,
>> and rewrite fields in the messages that refer to the template ID's.
>>
>> mark
>>
>> On Dec 23, 2003, at 2:12 PM, Meyer, Jeffrey D (http://usage.fc.hp.c)
>> wrote:
>>
>>> Mark,
>>>
>>>   Agreed, it is a choice, and both will work, it is a questions of
>>> anticipated extensibility.  Fewer fields in the header and most
>>> information elements defined in a consistent manner seems to me to
>>> address the approach of "Make it as simple as possible and no
>>> simpler".
>>>
>>>   Since the requirement appears to be addressable with a single
>>> mechanism, i.e. a flag distinguishing options from flow elements, and
>>> reusing the information modeling, I still don't see the benefit in
>>> introducing more mechanisms which need to be implemented and tested on
>>> both ends.
>>>
>>> -- Jeff
>>>
>>> -----Original Message-----
>>> From: Mark Fullmer [mailto:maf@eng.oar.net]
>>> Sent: Tuesday, December 23, 2003 10:11 AM
>>> To: Meyer, Jeffrey D (http://usage.fc.hp.c)
>>> Cc: ipfix@net.doit.wisc.edu; Benoit Claise
>>> Subject: Re: [ipfix] Option templates issues
>>>
>>>
>>> There are two issues here
>>>
>>>    1) How to provide extra information about the flow data and metering
>>>       process.
>>>
>>>    2) How to allow for protocol extensions.
>>>
>>> If we add a required "key" or "command" field to the options templates
>>> then I think what we have will work given the proper text
>>> describing what IE's MAY, SHOULD, and MUST be present in an options
>>> template with a specific key.  We may want to even have a separate
>>> IE namespace for the options....
>>>
>>> The protocol extension I'm still of the opinion should be handled
>>> with an extensible header.  Examples of protocol extensions could be
>>>
>>>     Reliable fail-over.
>>>
>>>     Authentication.
>>>
>>>     The optional time stamp for the split-time model.
>>>
>>>     Hooks for proxies.
>>>
>>>     Future unanticipated extensions.
>>>
>>> And yes, all of this could be stuffed in an options template but the
>>> same
>>> argument could be used to do away with the protocol header entirely.
>>>
>>> mark
>>>
>>>
>>> On Dec 22, 2003, at 11:17 AM, Meyer, Jeffrey D (http://usage.fc.hp.c)
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>   Again, I'd point out, that as Benoit indicates, there are likely to
>>>> be different things we want to send as "options".
>>>>
>>>>   Rather than inventing an entirely new model, just make option a
>>>> flag on the template and REUSE what we already have for data records.
>>>> It's that simple!
>>>>
>>>> -- Jeff
>>>>
>>>> -----Original Message-----
>>>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
>>>> Behalf
>>>> Of Benoit Claise
>>>> Sent: Monday, December 22, 2003 4:04 AM
>>>> To: Mark Fullmer
>>>> Cc: ipfix@net.doit.wisc.edu
>>>> Subject: Re: [ipfix] Option templates issues
>>>>
>>>>
>>>> Mark,
>>>>
>>>> [sorry for the delay, i've been absent from the list for a while]
>>>>
>>>> I understand the concern but let me ask a few questions.
>>>> What if the metering process can't "meter" one of them? Ex: flows not
>>>> exported due to resource starvation
>>>> What if we would like to export some extra data types? Ex: IPv6
>>>> packets
>>>> and bytes dropped
>>>> So what if the METERSTAT struct is slightly modified?
>>>>
>>>> Ganesh had a good point I think:
>>>>     If the group can come up with fixed structs that you mentioned
>>>> below,
>>>>     then I think what you propose can be adopted.
>>>>
>>>> Aren't we going to spend a long time to determine what MUST be
>>>> exported
>>>> in this/those structure(s)?
>>>> What you defined in your METERSTAT makes perfectly from a collector
>>>> point of view but will not always be possible to collect on the
>>>> exporter?
>>>> And it does perfectly sense now, but what about in 1 year? So would we
>>>> have a new data type with a new slightly different structure?
>>>>
>>>> I'm just wondering what we should say in the protocol draft:
>>>>     1. SHOULD export a METERSTAT data type(as described in your
>>>> email)?
>>>> What if one data type can't be exported, we don't send any metering
>>>> stats "message"?
>>>>     2. MUST export a metering statistics Options Templates that SHOULD
>>>> contain lost_flows, lost_flows_pkts, lost_flows_bytes, lost_pkts,
>>>> lost_bytes, time.
>>>>     3. MUST export a metering statistics Options Templates that MUST
>>>> contain X, Y, and SHOULD contain Z
>>>>     4. MUST export a metering statistics Options Templates that
>>>> contain
>>>> at least X, Y
>>>>
>>>> Actually, I think the flexibility of the Options Template is
>>>> benefitial
>>>> for any data types.
>>>>
>>>> Now, this is a different story for the Hello, Failover, etc... types
>>>> of
>>>> messages that you spoke about, as the goal is totally different!
>>>>
>>>> Regards, Benoit.
>>>>
>>>>>
>>>>> I'd like to propose an alternative mechanism for sending auxiliary
>>>>> data such
>>>>> as time synch messages, protocol hellos (needed for fail-over),
>>>>> metering
>>>>> process loss statistics (ie packets/flows lost due to resource
>>>>> starvation),
>>>>> etc.
>>>>>
>>>>> The existing framework allows "other" data to be sent in options
>>>>> templates.
>>>>> Take for example a metering process stat message.  Lets say the
>>>>> metering
>>>>> process will periodically report statistics such as
>>>>>
>>>>>   struct METERSTAT {
>>>>>     u_int32_t lost_flows;       /* flows not exported due to resource
>>>>> starvation */
>>>>>     u_int32_t lost_flows_pkts;  /* packets in the lost flows */
>>>>>     u_int32_t lost_flows_bytes; /* bytes in the lost flows */
>>>>>     u_int32_t lost_pkts;   /* packets dropped by metering process */
>>>>>     u_int32_t lost_bytes;  /* bytes dropped by metering process */
>>>>>     time_t    now;         /* when this record was generated */
>>>>>   };
>>>>>
>>>>>   The question becomes how to encode this with an options template.
>>>>>
>>>>>   Each field in the record could have a type (6 types), then the
>>>>> options template
>>>>>   would list each of the 6 types.  The problem here is during
>>>>> decoding.  What
>>>>>   will the collector do if only 5 of these items show up.  The packet
>>>>> decode
>>>>>   process is also not very straightforward when just data is sent
>>>>> (other option
>>>>>   fields could be in the same template) because it will have to
>>>>> figure
>>>>> out
>>>>>   what to do based on the field type and there's no way to group
>>>>> fields.
>>>>
>>>>
>>>>>
>>>>>   The other option is to call METERSTAT a type (of length 24).  Now
>>>>> the
>>>>>   decode process can key off of the type and all the fields will
>>>>> always be
>>>>>   there because METERSTAT is fixed and defined in the protocol
>>>>> document just
>>>>>   like other fields like PACKETS, BYTES, PROTOCOL, etc.  The issue I
>>>>> have here
>>>>>   is why are we bothering with a template/data model for this.  Why
>>>>> not just
>>>>>   use traditional TLV's.
>>>>>
>>>>>   So what I'd like to see (I think) is to take one of the existing
>>>>> reserved
>>>>>   flowset ID's, lets say 3 and use it for generic TLV data encodings.
>>>>> Then
>>>>>   define structured data in the protocol such as METERSTAT.  IMHO
>>>>> this
>>>>> allows us
>>>>>   to address a number of other issues including how to add HELLO's
>>>>> for
>>>>> the
>>>>>   (optional) reliable failover, how to add aux flags like "this is
>>>>> potentially
>>>>>   a duplicate PDU because I failed over", etc.
>>>>>
>>>>>   The TLV encodings would only be used for the low bit-rate protocol
>>>>> messages,
>>>>>   NOT the high bandwidth flow data.  I'm also not proposing the
>>>>> option
>>>>> templates
>>>>>   go away, just that we use a more traditional method for encoding
>>>>> the
>>>>> non flow
>>>>>   data.
>>>>>
>>>>> mark
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>>>>> message body
>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>> "unsubscribe ipfix" in message body
>>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>>>> message body
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>
>>
>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
> 
> 
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 12 09:48:28 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28477
	for <ipfix-archive@lists.ietf.org>; Mon, 12 Jan 2004 09:48:27 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Ag3Ap-0007gP-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jan 2004 08:36:11 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1Ag3Ao-0007gJ-00
	for ipfix@net.doit.wisc.edu; Mon, 12 Jan 2004 08:36:10 -0600
Received: (qmail 5623 invoked by alias); 12 Jan 2004 14:36:09 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 12 Jan 2004 14:36:09 -0000
In-Reply-To: <400285CB.6090500@cisco.com>
References: <A747B346BDCCAB45831C24F0CD7C7F09177D3F@cacexc03.americas.cpqcorp.net> <8070399F-449E-11D8-BCCB-000A95DA1C38@eng.oar.net> <400285CB.6090500@cisco.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <A873F20E-450C-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>,
        "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Option templates issues
Date: Mon, 12 Jan 2004 09:36:07 -0500
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


On Jan 12, 2004, at 6:32 AM, Stewart Bryant wrote:

>
> Will we ever need to run IPFIX though a NAT? ie, can we reply on the
> IP address to be globally unique? If so we only need to worry
> about the v4/v6 issues with including it in the IPFIX message.
> If not then perhaps we need to use a real UID rather than IP address
> plus local ID.

I don't think this matters.  A NAT would not modify this field, it's
there so a collector knows the real IP address of the exporter.  This
is useful in itself as a unique ID or possibly to allow the collector
to query the exporter, say with SNMP.

>> Slightly unrelated is another need for a HELLO or keep-alive.  
>> Currently
>> there's no way for a collector to tell the difference between a broken
>> exporter configuration and a quiet exporter generating no data.  This
>> is less of an issue for TCP/SCTP transports which will eventually 
>> close
>> due to timeouts, but that's still usually on the order of hours for 
>> TCP.
>
> Won't we see templates from time to time?

Depends.  If the transport is reliable there is no need to refresh
template state.

--
mark


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 12 10:41:37 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02521
	for <ipfix-archive@lists.ietf.org>; Mon, 12 Jan 2004 10:41:31 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Ag415-0001cc-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jan 2004 09:30:11 -0600
Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Ag414-0001cW-00
	for ipfix@net.doit.wisc.edu; Mon, 12 Jan 2004 09:30:10 -0600
Received: from 207-237-36-98.c3-0.avec-ubr10.nyr-avec.ny.cable.rcn.com ([207.237.36.98] helo=osiris)
	by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4)
	id 1Ag413-0001LE-00; Mon, 12 Jan 2004 10:30:09 -0500
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: "'Mark Fullmer'" <maf@eng.oar.net>,
        "''Ipfix Wg' \(E-mail\)'" <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Fwd: NetFlow v.x timestamp rollover
Date: Mon, 12 Jan 2004 10:30:06 -0500
Organization: QoSient, LLC
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-reply-to: <424B84EE-44A0-11D8-BCCB-000A95DA1C38@eng.oar.net>
Thread-Index: AcPYrVonZmZpIjT4R+aVLBhGkAwijgAc1UEw
Message-Id: <E1Ag413-0001LE-00@smtp02.mrf.mail.rcn.net>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This situation also doesn't happen when real time is
provided in the flow records to begin with.  Providing
relative time only generates limitations for the protocol,
since it forces "scope" on what should be a streaming
protocol.  At present IPFIX can only be a block protocol.

Carter


-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
Mark Fullmer
Sent: Sunday, January 11, 2004 8:40 PM
To: 'Ipfix Wg' (E-mail)
Subject: [ipfix] Fwd: NetFlow v.x timestamp rollover

<resending with a valid source address>

Begin forwarded message:

> From: Mark Fullmer <maf@splintered.net>
> Date: January 11, 2004 7:59:51 PM EST
> To: 'Ipfix Wg' (E-mail) <ipfix@net.doit.wisc.edu>
> Cc: Benoit Claise <bclaise@cisco.com>
> Subject: NetFlow v.x timestamp rollover
>
> Benoit asked for a clarification on the NetFlow vx timestamp rollover
> circumstance.
>
> Start and End time represent the router uptime in milliseconds.  This
> will rollover at 3^32-1 milliseconds or about every 49 days.  If a flow
> is created near this border the Start time will be greater then the
> End time.  For example
>
> Time  Event
> -------------------
> T1    router uptime is 4294967290 ms.
> T2    flow is created at sysUpTime of 4294967290.
> T3    flow is ended at sysUpTime of 4294967296 ms.
> T4    flow is expired at sysUpTime of 4294967297 ms.
>
> 4294967296 doesn't fit in 32 bits so the End time will be 0 due to
> rollover.  The header sysUptime will then be 1.
>
> If an application is using the header {sysUpTime,unix_secs,unix_nsecs)
> to
> convert the flow {End,Start} time to real time it needs to be careful
> to take this rollover into consideration.
>
> Ditto for calculating flow durations.
>
> This situation does not happen in what we've been calling "split-time".
>
> --
> mark
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 12 11:27:09 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04401
	for <ipfix-archive@lists.ietf.org>; Mon, 12 Jan 2004 11:27:08 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Ag4aH-0002pd-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jan 2004 10:06:33 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Ag4aG-0002pY-00
	for ipfix@net.doit.wisc.edu; Mon, 12 Jan 2004 10:06:32 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 12 Jan 2004 17:07:19 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i0CG6Cva024593;
	Mon, 12 Jan 2004 17:06:12 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp4327.cisco.com [10.61.80.230])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA13429;
	Mon, 12 Jan 2004 16:06:29 GMT
Message-ID: <4002C601.6060006@cisco.com>
Date: Mon, 12 Jan 2004 16:06:25 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>,
        "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>
Subject: Re: [ipfix] Option templates issues
References: <A747B346BDCCAB45831C24F0CD7C7F09177D3F@cacexc03.americas.cpqcorp.net> <8070399F-449E-11D8-BCCB-000A95DA1C38@eng.oar.net> <400285CB.6090500@cisco.com> <A873F20E-450C-11D8-BCCB-000A95DA1C38@eng.oar.net>
In-Reply-To: <A873F20E-450C-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Mark Fullmer wrote:

> 
> On Jan 12, 2004, at 6:32 AM, Stewart Bryant wrote:
> 
>>
>> Will we ever need to run IPFIX though a NAT? ie, can we reply on the
>> IP address to be globally unique? If so we only need to worry
>> about the v4/v6 issues with including it in the IPFIX message.
>> If not then perhaps we need to use a real UID rather than IP address
>> plus local ID.
> 
> 
> I don't think this matters.  A NAT would not modify this field, it's
> there so a collector knows the real IP address of the exporter.  This
> is useful in itself as a unique ID or possibly to allow the collector
> to query the exporter, say with SNMP.

But the IP address on the far side of a NAT (which is the one that would be
in the IPFIX message) is not globally unique and therefore you could have
an alias.

> 
>>> Slightly unrelated is another need for a HELLO or keep-alive.  Currently
>>> there's no way for a collector to tell the difference between a broken
>>> exporter configuration and a quiet exporter generating no data.  This
>>> is less of an issue for TCP/SCTP transports which will eventually close
>>> due to timeouts, but that's still usually on the order of hours for TCP.
>>
>>
>> Won't we see templates from time to time?
> 
> 
> Depends.  If the transport is reliable there is no need to refresh
> template state.

But if there is a reliable transport it will have some form of hello,
and it's just a question of tuning its timing.

- Stewart

> 
> -- 
> mark
> 
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 12 11:30:45 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04524
	for <ipfix-archive@lists.ietf.org>; Mon, 12 Jan 2004 11:30:45 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Ag4it-0002w9-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jan 2004 10:15:27 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1Ag4is-0002w2-00
	for ipfix@net.doit.wisc.edu; Mon, 12 Jan 2004 10:15:26 -0600
Received: (qmail 6124 invoked by alias); 12 Jan 2004 16:15:23 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 12 Jan 2004 16:15:23 -0000
In-Reply-To: <E1Ag413-0001LE-00@smtp02.mrf.mail.rcn.net>
References: <E1Ag413-0001LE-00@smtp02.mrf.mail.rcn.net>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <85CA203E-451A-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "''Ipfix Wg' \(E-mail\)'" <ipfix@net.doit.wisc.edu>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Fwd: NetFlow v.x timestamp rollover
Date: Mon, 12 Jan 2004 11:15:22 -0500
To: <carter@qosient.com>
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

IPFIX will support at least the 64 bit NTP format absolute Start and End
timestamps.  The split-time IE will be available as an optimization
to reduce bandwidth.  Collectors will obviously need to support both.

mark

On Jan 12, 2004, at 10:30 AM, Carter Bullard wrote:

> This situation also doesn't happen when real time is
> provided in the flow records to begin with.  Providing
> relative time only generates limitations for the protocol,
> since it forces "scope" on what should be a streaming
> protocol.  At present IPFIX can only be a block protocol.
>
> Carter
>
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On 
> Behalf Of
> Mark Fullmer
> Sent: Sunday, January 11, 2004 8:40 PM
> To: 'Ipfix Wg' (E-mail)
> Subject: [ipfix] Fwd: NetFlow v.x timestamp rollover
>
> <resending with a valid source address>
>
> Begin forwarded message:
>
>> From: Mark Fullmer <maf@splintered.net>
>> Date: January 11, 2004 7:59:51 PM EST
>> To: 'Ipfix Wg' (E-mail) <ipfix@net.doit.wisc.edu>
>> Cc: Benoit Claise <bclaise@cisco.com>
>> Subject: NetFlow v.x timestamp rollover
>>
>> Benoit asked for a clarification on the NetFlow vx timestamp rollover
>> circumstance.
>>
>> Start and End time represent the router uptime in milliseconds.  This
>> will rollover at 3^32-1 milliseconds or about every 49 days.  If a 
>> flow
>> is created near this border the Start time will be greater then the
>> End time.  For example
>>
>> Time  Event
>> -------------------
>> T1    router uptime is 4294967290 ms.
>> T2    flow is created at sysUpTime of 4294967290.
>> T3    flow is ended at sysUpTime of 4294967296 ms.
>> T4    flow is expired at sysUpTime of 4294967297 ms.
>>
>> 4294967296 doesn't fit in 32 bits so the End time will be 0 due to
>> rollover.  The header sysUptime will then be 1.
>>
>> If an application is using the header {sysUpTime,unix_secs,unix_nsecs)
>> to
>> convert the flow {End,Start} time to real time it needs to be careful
>> to take this rollover into consideration.
>>
>> Ditto for calculating flow durations.
>>
>> This situation does not happen in what we've been calling 
>> "split-time".
>>
>> --
>> mark
>>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 12 11:44:15 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05100
	for <ipfix-archive@lists.ietf.org>; Mon, 12 Jan 2004 11:44:14 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Ag4yl-0003MD-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jan 2004 10:31:51 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1Ag4yl-0003M8-00
	for ipfix@net.doit.wisc.edu; Mon, 12 Jan 2004 10:31:51 -0600
Received: (qmail 6197 invoked by alias); 12 Jan 2004 16:31:50 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 12 Jan 2004 16:31:50 -0000
In-Reply-To: <4002C601.6060006@cisco.com>
References: <A747B346BDCCAB45831C24F0CD7C7F09177D3F@cacexc03.americas.cpqcorp.net> <8070399F-449E-11D8-BCCB-000A95DA1C38@eng.oar.net> <400285CB.6090500@cisco.com> <A873F20E-450C-11D8-BCCB-000A95DA1C38@eng.oar.net> <4002C601.6060006@cisco.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D1BE911E-451C-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>,
        "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] Option templates issues
Date: Mon, 12 Jan 2004 11:31:48 -0500
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


On Jan 12, 2004, at 11:06 AM, Stewart Bryant wrote:

>> On Jan 12, 2004, at 6:32 AM, Stewart Bryant wrote:
>>>
>>> Will we ever need to run IPFIX though a NAT? ie, can we reply on the
>>> IP address to be globally unique? If so we only need to worry
>>> about the v4/v6 issues with including it in the IPFIX message.
>>> If not then perhaps we need to use a real UID rather than IP address
>>> plus local ID.
>> I don't think this matters.  A NAT would not modify this field, it's
>> there so a collector knows the real IP address of the exporter.  This
>> is useful in itself as a unique ID or possibly to allow the collector
>> to query the exporter, say with SNMP.
>
> But the IP address on the far side of a NAT (which is the one that 
> would be
> in the IPFIX message) is not globally unique and therefore you could 
> have
> an alias.

Okay, so if an exporter is behind a NAT this field would not be valid.

I'll leave this at it's a potential problem...

>
>>>> Slightly unrelated is another need for a HELLO or keep-alive.  
>>>> Currently
>>>> there's no way for a collector to tell the difference between a 
>>>> broken
>>>> exporter configuration and a quiet exporter generating no data.  
>>>> This
>>>> is less of an issue for TCP/SCTP transports which will eventually 
>>>> close
>>>> due to timeouts, but that's still usually on the order of hours for 
>>>> TCP.
>>>
>>>
>>> Won't we see templates from time to time?
>> Depends.  If the transport is reliable there is no need to refresh
>> template state.
>
> But if there is a reliable transport it will have some form of hello,
> and it's just a question of tuning its timing.

TCP keepalives are generally two hours and not easily modified.

Back to template retransmissions....The retransmission timer is 
currently
not specified in the protocol, so the collector wouldn't know how to set
a timeout alarm.

>
> - Stewart
>
>> -- 
>> mark
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 12 13:26:09 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09607
	for <ipfix-archive@lists.ietf.org>; Mon, 12 Jan 2004 13:26:08 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Ag6Zg-0006Mi-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jan 2004 12:14:04 -0600
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Ag6Zf-0006Mc-00
	for ipfix@net.doit.wisc.edu; Mon, 12 Jan 2004 12:14:03 -0600
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0CIDqe16564
	for <ipfix@net.doit.wisc.edu>; Mon, 12 Jan 2004 12:13:53 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <ZPPAK11B>; Mon, 12 Jan 2004 18:57:43 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550350992D@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Mark Fullmer <maf@eng.oar.net>,
        "'Ipfix Wg' (E-mail)"
	 <ipfix@net.doit.wisc.edu>
Cc: Benoit Claise <bclaise@cisco.com>
Subject: RE: [ipfix] protocol security section
Date: Mon, 12 Jan 2004 18:57:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Inline

> -----Original Message-----
> From: Mark Fullmer [mailto:maf@eng.oar.net]
> Sent: maandag 12 januari 2004 4:40
> To: 'Ipfix Wg' (E-mail)
> Cc: Benoit Claise
> Subject: [ipfix] protocol security section
> 
> 
> This is a rough draft of a security section.  I'd like to be able to
> enumerate the attack scenarios better but this requires we get the
> UDP/no UDP directive and relating issues behind us.  I think at least
> all the issues are here.
> 
> I'm also leaning towards a simple authentication (plain text password
> for example) option available in the protocol so that a collector can
> at least have some idea who its talking to without requiring IPSec.
> 
I am pretty sure that IESG will NOT bless a "plain text password"
authentication method.

> ---
> 
> The IPFIX protocol provides no means to secure messages between the
> exporter and collector, or a mechanism to provide for mutual
> authentication.  IPSec MAY be used for message authentication and or
> encryption, but this may not address all the security issues present
> in an IPFIX deployment.
> 
Syaing "use IPsec" (MUST/SHOULD oR MAY) is NOT sufficient.
You have to explain how it is to be used etc.
See draft-bellovin-useipsec-02.txt for guidelines.

Hope this helps,
Bert

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 12 13:27:38 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09630
	for <ipfix-archive@lists.ietf.org>; Mon, 12 Jan 2004 13:27:37 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Ag6ZV-0006MY-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jan 2004 12:13:53 -0600
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Ag6ZU-0006MS-00
	for ipfix@net.doit.wisc.edu; Mon, 12 Jan 2004 12:13:52 -0600
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0CIDme16473
	for <ipfix@net.doit.wisc.edu>; Mon, 12 Jan 2004 12:13:48 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <ZPPAK11A>; Mon, 12 Jan 2004 18:57:43 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550350992C@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Mark Fullmer <maf@eng.oar.net>,
        "'Ipfix Wg' (E-mail)"
	 <ipfix@net.doit.wisc.edu>
Subject: RE: [ipfix] Fwd: NetFlow v.x timestamp rollover
Date: Mon, 12 Jan 2004 18:57:42 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

> > Time  Event
> > -------------------
> > T1    router uptime is 4294967290 ms.
> > T2    flow is created at sysUpTime of 4294967290.
> > T3    flow is ended at sysUpTime of 4294967296 ms.
> > T4    flow is expired at sysUpTime of 4294967297 ms.
> >
> > 4294967296 doesn't fit in 32 bits so the End time will be 0 due to
> > rollover.  The header sysUptime will then be 1.
> >

I would appreciate if you guys find another name for sysUpTime.
People may confuse it with the MIB sysUpTime value. But that
MIB related sysUpTime is represented in centi-seconds, not ms.

The original Netflow spec (on my plate right now for informational doc)
even had text in there that linked it to the MIB sysUpTime. And that
is wrong.

Bert

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 12 19:26:08 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01730
	for <ipfix-archive@lists.ietf.org>; Mon, 12 Jan 2004 19:26:07 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AgBrL-0007jz-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jan 2004 17:52:39 -0600
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AgBrK-0007js-00
	for ipfix@net.doit.wisc.edu; Mon, 12 Jan 2004 17:52:38 -0600
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0CNp1605025
	for <ipfix@net.doit.wisc.edu>; Mon, 12 Jan 2004 17:51:13 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <ZPPALBP2>; Tue, 13 Jan 2004 00:51:00 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503509970@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Benoit Claise <bclaise@cisco.com>
Cc: ipfix <ipfix@net.doit.wisc.edu>, Stewart Bryant <stbryant@cisco.com>,
        Mark Fullmer <maf@eng.oar.net>, peter.lei@ieee.org
Subject: RE: [ipfix] [issue] wording of transport protocol support
Date: Tue, 13 Jan 2004 00:50:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3D966.E9229478"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3D966.E9229478
Content-Type: text/plain

I am working on this right now with Transport ADs.
 
Sorry that it got delayed so long.
 

Thanks,
Bert 

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: donderdag 8 januari 2004 17:46
To: Wijnen, Bert (Bert)
Cc: ipfix; Stewart Bryant; Mark Fullmer; peter.lei@ieee.org
Subject: Re: [ipfix] [issue] wording of transport protocol support


Hello Bert,


I will give it a try. But I need some time.

Have you had the chance to think about some text?

Mark and I will be publishing a new version of the protocol draft in a few working days.

Regards, Benoit.


 

Thanks,
Bert 

-----Original Message-----
From: Benoit Claise [ mailto:bclaise@cisco.com <mailto:bclaise@cisco.com> ]
Sent: dinsdag 23 december 2003 17:31
To: ipfix
Cc: Wijnen, Bert (Bert); Stewart Bryant; Mark Fullmer; peter.lei@ieee.org <mailto:peter.lei@ieee.org> 
Subject: RE: [ipfix] [issue] wording of transport protocol support


Dear all,

As the editor of the protocol draft trying to add some text to the draft, let me try to summarize the situation in order to move forward.
If I wrongly summarized the situation, I'm sure I will stand corrected ;)

>From the proposed text: 


     SCTP SHOULD be used in deployments where exporters and collectors

     are communicating over links which are susceptible to congestion.

     TCP MAY be used in deployments where exporters and collectors

     communicate over links which are suscepible to congestion, but SCTP

     is preferred, due to its ability to limit back pressure on exporters

     (especially when using PR-SCTP) and its message vs. stream orientation.

 

     Other non-congestion aware protocols MAY be used in deployments where

     exporters and collectors always communicate over dedicated links 

     which are not susceptible to congestion.



We still have the issue of one MUST transport protocol, as mentionned by Bert.

So back to where we were. (personally I was thinking it was a nice solution for the ongoing transport issue though)



But do I understand correctly, from Bert's comments below, that we are on the right track with the last paragraph?

We must nevertheless add some warning text to it to cover the following issue:

    
some more WARNING text as to what the
risks are, so that if people decide to use it over 
non-congestion-avoiding protocols, that they can easily evaluate what
the risks are and make an educated decision

Someone wants to give it a try?



Regards, Benoit.



    


-------- Original Message -------- 
Subject: 	RE: [ipfix] [issue] wording of transport protocol support	
Date: 	Fri, 21 Nov 2003 17:02:54 +0100	
From: 	Wijnen, Bert (Bert)  <mailto:bwijnen@lucent.com> <bwijnen@lucent.com>	
To: 	Randall Stewart (cisco)  <mailto:rrs@cisco.com> <rrs@cisco.com>	
CC: 	stbryant@cisco.com <mailto:stbryant@cisco.com> , Mark Fullmer  <mailto:maf@eng.oar.net> <maf@eng.oar.net>, Peter Lei  <mailto:peter.lei@ieee.org> <peter.lei@ieee.org>, "'ipfix wg'"  <mailto:ipfix@net.doit.wisc.edu> <ipfix@net.doit.wisc.edu>	


> Bert:

> 

> I clip in from my previous post what Allision and Jon were ok with:

> 

> "

>     SCTP SHOULD be used in deployments where exporters and collectors

>     are communicating over links which are susceptible to congestion.

>     TCP MAY be used in deployments where exporters and collectors

>     communicate over links which are suscepible to congestion, but SCTP

>     is preferred, due to its ability to limit back pressure on exporters

>     (especially when using PR-SCTP) and its message vs. stream orientation.

> 

>    Other non-congestion aware protocols MAY be used in deployments where

>    exporters and collectors always communicate over dedicated links 

>    which are not susceptible to congestion.

> "

> 

> 

> Now notice the subtle changing of the last paragraph that 

> Allision wanted:

> 

> ---exporters an collectors always communicate over didicated links---

>                                         ^^^^^^

> 

That is goodness.



> This basically limits any such deployment to a private network 

> connection between the collector and exporter that is NOT connected

> to the internet backbone i.e. its a 10.x.x.x address. In such a case

> I think it would be ok...

>

> Do you still have a problem with this?



In a 10.x.x.x network, one can still cause havoc off course.

But one can say: oh well that is the users responsibility.

I personally would like to see some more WARNING text as to what the

risks are, so that if people decide to use it over 

non-congestion-avoiding protocols, that they can easily evaluate what

the risks are and make an educated decision.



When you say dedicated link, I imagines a dedicated link between 

exporter and collector. But when you start to talk about a 10.x.x.x

network, all of a sudden it could be a internal company wide network.

OK, it does not hurt the public Internet, but it still hurts the

company network.



The language about SHOULD use SCTP and MAY use TCP makes me worry

that one can easily end up with non-interoperable implementations

where a customer buys a exporter and collector from X with SCTP

support and next buys another exporter from Y with TCP support.

How will these interopearte??



That is why I prefer a MUST implement ONE of the transports.

Which one is up to the WG.



Hope this helps.

Bert



> 

> R

> 

> 

> -- 

> Randall R. Stewart

> ITD

> Cisco Systems Inc.

>  rrs@cisco.com <mailto:rrs@cisco.com>  815-342-5222(cell) or 815-477-2127(office)

> 

> 



--

Help         mailto:majordomo@net.doit.wisc.edu <mailto:majordomo@net.doit.wisc.edu>  and say "help" in message body

Unsubscribe  mailto:majordomo@net.doit.wisc.edu <mailto:majordomo@net.doit.wisc.edu>  and say

"unsubscribe ipfix" in message body

Archive      http://ipfix.doit.wisc.edu/archive/ <http://ipfix.doit.wisc.edu/archive/> 

    



------_=_NextPart_001_01C3D966.E9229478
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE></TITLE>

<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><SPAN class=523145014-12012004><FONT face=Arial color=#0000ff size=2>I am 
working on this right now with Transport ADs.</FONT></SPAN></DIV>
<DIV><SPAN class=523145014-12012004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=523145014-12012004><FONT face=Arial color=#0000ff size=2>Sorry 
that it got delayed so long.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=2>Thanks,<BR>Bert </FONT></P>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Benoit Claise 
  [mailto:bclaise@cisco.com]<BR><B>Sent:</B> donderdag 8 januari 2004 
  17:46<BR><B>To:</B> Wijnen, Bert (Bert)<BR><B>Cc:</B> ipfix; Stewart Bryant; 
  Mark Fullmer; peter.lei@ieee.org<BR><B>Subject:</B> Re: [ipfix] [issue] 
  wording of transport protocol support<BR><BR></FONT></DIV>Hello Bert,<BR>
  <BLOCKQUOTE 
  cite="mid7D5D48D2CAA3D84C813F5B154F43B155033D2CAB@nl0006exch001u.nl.lucent.com" 
  type="cite">
    <META content="MSHTML 5.50.4807.2300" name=GENERATOR>
    <DIV><SPAN class=227484616-23122003><FONT face=Arial color=#0000ff size=2>I 
    will give it a try. But I need some time.</FONT></SPAN></DIV></BLOCKQUOTE>Have 
  you had the chance to think about some text?<BR><BR>Mark and I will be 
  publishing a new version of the protocol draft in a few working 
  days.<BR><BR>Regards, Benoit.<BR>
  <BLOCKQUOTE 
  cite="mid7D5D48D2CAA3D84C813F5B154F43B155033D2CAB@nl0006exch001u.nl.lucent.com" 
  type="cite">
    <DIV>&nbsp;</DIV>
    <P><FONT size=2>Thanks,<BR>Bert </FONT></P>
    <BLOCKQUOTE dir=ltr 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(0,0,255) 2px solid; MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Benoit Claise [<A 
      class=moz-txt-link-freetext 
      href="mailto:bclaise@cisco.com">mailto:bclaise@cisco.com</A>]<BR><B>Sent:</B> 
      dinsdag 23 december 2003 17:31<BR><B>To:</B> ipfix<BR><B>Cc:</B> Wijnen, 
      Bert (Bert); Stewart Bryant; Mark Fullmer; <A 
      class=moz-txt-link-abbreviated 
      href="mailto:peter.lei@ieee.org">peter.lei@ieee.org</A><BR><B>Subject:</B> 
      RE: [ipfix] [issue] wording of transport protocol 
      support<BR><BR></FONT></DIV>Dear all,<BR><BR>As the editor of the protocol 
      draft trying to add some text to the draft, let me try to summarize the 
      situation in order to move forward.<BR>If I wrongly summarized the 
      situation, I'm sure I will stand corrected ;)<BR><BR>&gt;From the proposed 
      text: <BR><BR><PRE>     SCTP SHOULD be used in deployments where exporters and collectors
     are communicating over links which are susceptible to congestion.
     TCP MAY be used in deployments where exporters and collectors
     communicate over links which are suscepible to congestion, but SCTP
     is preferred, due to its ability to limit back pressure on exporters
     (especially when using PR-SCTP) and its message vs. stream orientation.
 
     Other non-congestion aware protocols MAY be used in deployments where
     exporters and collectors always communicate over dedicated links 
     which are not susceptible to congestion.

We still have the issue of one MUST transport protocol, as mentionned by Bert.
So back to where we were. (personally I was thinking it was a nice solution for the ongoing transport issue though)

But do I understand correctly, from Bert's comments below, that we are on the right track with the last paragraph?
We must nevertheless add some warning text to it to cover the following issue:
    </PRE>
      <DIV style="MARGIN-LEFT: 40px">some more WARNING text as to what 
      the<BR>risks are, so that if people decide to use it over 
      <BR>non-congestion-avoiding protocols, that they can easily evaluate 
      what<BR>the risks are and make an educated decision<BR></DIV><PRE>Someone wants to give it a try?

Regards, Benoit.

    </PRE><BR><BR>-------- Original Message -------- 
      <TABLE cellSpacing=0 cellPadding=0 border=0>
        <TBODY>
        <TR>
          <TH vAlign=baseline noWrap align=right>Subject: </TH>
          <TD>RE: [ipfix] [issue] wording of transport protocol support</TD></TR>
        <TR>
          <TH vAlign=baseline noWrap align=right>Date: </TH>
          <TD>Fri, 21 Nov 2003 17:02:54 +0100</TD></TR>
        <TR>
          <TH vAlign=baseline noWrap align=right>From: </TH>
          <TD>Wijnen, Bert (Bert) <A class=moz-txt-link-rfc2396E 
            href="mailto:bwijnen@lucent.com">&lt;bwijnen@lucent.com&gt;</A></TD></TR>
        <TR>
          <TH vAlign=baseline noWrap align=right>To: </TH>
          <TD>Randall Stewart (cisco) <A class=moz-txt-link-rfc2396E 
            href="mailto:rrs@cisco.com">&lt;rrs@cisco.com&gt;</A></TD></TR>
        <TR>
          <TH vAlign=baseline noWrap align=right>CC: </TH>
          <TD><A class=moz-txt-link-abbreviated 
            href="mailto:stbryant@cisco.com">stbryant@cisco.com</A>, Mark 
            Fullmer <A class=moz-txt-link-rfc2396E 
            href="mailto:maf@eng.oar.net">&lt;maf@eng.oar.net&gt;</A>, Peter Lei 
            <A class=moz-txt-link-rfc2396E 
            href="mailto:peter.lei@ieee.org">&lt;peter.lei@ieee.org&gt;</A>, 
            "'ipfix wg'" <A class=moz-txt-link-rfc2396E 
            href="mailto:ipfix@net.doit.wisc.edu">&lt;ipfix@net.doit.wisc.edu&gt;</A></TD></TR></TBODY></TABLE><BR><BR><PRE>&gt; Bert:
&gt; 
&gt; I clip in from my previous post what Allision and Jon were ok with:
&gt; 
&gt; "
&gt;     SCTP SHOULD be used in deployments where exporters and collectors
&gt;     are communicating over links which are susceptible to congestion.
&gt;     TCP MAY be used in deployments where exporters and collectors
&gt;     communicate over links which are suscepible to congestion, but SCTP
&gt;     is preferred, due to its ability to limit back pressure on exporters
&gt;     (especially when using PR-SCTP) and its message vs. stream orientation.
&gt; 
&gt;    Other non-congestion aware protocols MAY be used in deployments where
&gt;    exporters and collectors always communicate over dedicated links 
&gt;    which are not susceptible to congestion.
&gt; "
&gt; 
&gt; 
&gt; Now notice the subtle changing of the last paragraph that 
&gt; Allision wanted:
&gt; 
&gt; ---exporters an collectors always communicate over didicated links---
&gt;                                         ^^^^^^
&gt; 
That is goodness.

&gt; This basically limits any such deployment to a private network 
&gt; connection between the collector and exporter that is NOT connected
&gt; to the internet backbone i.e. its a 10.x.x.x address. In such a case
&gt; I think it would be ok...
&gt;
&gt; Do you still have a problem with this?

In a 10.x.x.x network, one can still cause havoc off course.
But one can say: oh well that is the users responsibility.
I personally would like to see some more WARNING text as to what the
risks are, so that if people decide to use it over 
non-congestion-avoiding protocols, that they can easily evaluate what
the risks are and make an educated decision.

When you say dedicated link, I imagines a dedicated link between 
exporter and collector. But when you start to talk about a 10.x.x.x
network, all of a sudden it could be a internal company wide network.
OK, it does not hurt the public Internet, but it still hurts the
company network.

The language about SHOULD use SCTP and MAY use TCP makes me worry
that one can easily end up with non-interoperable implementations
where a customer buys a exporter and collector from X with SCTP
support and next buys another exporter from Y with TCP support.
How will these interopearte??

That is why I prefer a MUST implement ONE of the transports.
Which one is up to the WG.

Hope this helps.
Bert

&gt; 
&gt; R
&gt; 
&gt; 
&gt; -- 
&gt; Randall R. Stewart
&gt; ITD
&gt; Cisco Systems Inc.
&gt; <A class=moz-txt-link-abbreviated href="mailto:rrs@cisco.com">rrs@cisco.com</A> 815-342-5222(cell) or 815-477-2127(office)
&gt; 
&gt; 

--
Help        <A class=moz-txt-link-freetext href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> and say "help" in message body
Unsubscribe <A class=moz-txt-link-freetext href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=moz-txt-link-freetext href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</A>
    </PRE></BLOCKQUOTE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3D966.E9229478--

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 13 00:07:18 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13105
	for <ipfix-archive@lists.ietf.org>; Tue, 13 Jan 2004 00:07:18 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AgGWu-00002i-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jan 2004 22:51:52 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AgGWt-00002d-00
	for ipfix@net.doit.wisc.edu; Mon, 12 Jan 2004 22:51:51 -0600
Received: (qmail 10221 invoked by alias); 13 Jan 2004 04:51:50 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 13 Jan 2004 04:51:50 -0000
In-Reply-To: <4002790B.4020607@cisco.com>
References: <0F408853-44B1-11D8-BCCB-000A95DA1C38@eng.oar.net> <4002790B.4020607@cisco.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <32938C46-4584-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>,
        Benoit Claise <bclaise@cisco.com>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] protocol security section
Date: Mon, 12 Jan 2004 23:51:49 -0500
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


On Jan 12, 2004, at 5:38 AM, Stewart Bryant wrote:

>
> In <draft-ietf-l2tpext-l2tp-base-11.txt> which also has issues with
> IPsec being too heavy weight, it is proposed that blind insertion
> attacks be addressed through the use of a 64 bit cookie (a 64 bit
> randomly chosen password common to each end) is used. I am not sure
> whether this is going to be blessed by the IESG, but it would make
> sense is we used exactly the same approach and exactly the same
> argument (ie import their data plane security text). That way
> either both get accepted, or a common work item addresses the 
> shortfall.

How does the collector know the cookie is valid?

--
mark


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 13 07:08:08 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08298
	for <ipfix-archive@lists.ietf.org>; Tue, 13 Jan 2004 07:08:08 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AgMwh-0004rT-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jan 2004 05:42:55 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AgMwg-0004rN-00
	for ipfix@net.doit.wisc.edu; Tue, 13 Jan 2004 05:42:54 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 13 Jan 2004 12:43:40 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i0DBgXpA020514;
	Tue, 13 Jan 2004 12:42:33 +0100 (MET)
Received: from cisco.com (dhcp-rea-gp250-64-103-65-197.cisco.com [64.103.65.197])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA21283;
	Tue, 13 Jan 2004 11:42:51 GMT
Message-ID: <4003D9BB.10709@cisco.com>
Date: Tue, 13 Jan 2004 11:42:51 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>,
        Benoit Claise <bclaise@cisco.com>
Subject: Re: [ipfix] protocol security section
References: <0F408853-44B1-11D8-BCCB-000A95DA1C38@eng.oar.net> <4002790B.4020607@cisco.com> <32938C46-4584-11D8-BCCB-000A95DA1C38@eng.oar.net>
In-Reply-To: <32938C46-4584-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Mark Fullmer wrote:
> 
> On Jan 12, 2004, at 5:38 AM, Stewart Bryant wrote:
> 
>>
>> In <draft-ietf-l2tpext-l2tp-base-11.txt> which also has issues with
>> IPsec being too heavy weight, it is proposed that blind insertion
>> attacks be addressed through the use of a 64 bit cookie (a 64 bit
>> randomly chosen password common to each end) is used. I am not sure
>> whether this is going to be blessed by the IESG, but it would make
>> sense is we used exactly the same approach and exactly the same
>> argument (ie import their data plane security text). That way
>> either both get accepted, or a common work item addresses the shortfall.
> 
> 
> How does the collector know the cookie is valid?

In the L2TPv3 case, they are either reconfigured at both ends, or
signalled at session startup.

We could clearly preconfigure them, or we could exchange them over
a secure channel along with the template.

Stewart

> 
> -- 
> mark
> 
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 16 17:58:10 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03376
	for <ipfix-archive@lists.ietf.org>; Fri, 16 Jan 2004 17:58:10 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AhcUI-0001Zy-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jan 2004 16:30:46 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AhcUG-0001Zm-00
	for ipfix@net.doit.wisc.edu; Fri, 16 Jan 2004 16:30:45 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0GMUWkC028228
	for <ipfix@net.doit.wisc.edu>; Fri, 16 Jan 2004 23:30:34 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0GMUUsY028227
	for <ipfix@net.doit.wisc.edu>; Fri, 16 Jan 2004 23:30:30 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0GMUTkA028225; Fri, 16 Jan 2004 23:30:30 +0100 (CET)
Received: from [10.1.1.26] (dial02.office [10.1.1.26])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 3C509FA744; Fri, 16 Jan 2004 23:30:25 +0100 (CET)
Date: Fri, 16 Jan 2004 23:30:21 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: IESG comments on: draft-ietf-ipfix-reqs-13.txt
Message-ID: <2147483647.1074295821@[10.1.1.26]>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

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        quittek@ccrle.nec.de        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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sat Jan 17 17:37:36 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14686
	for <ipfix-archive@lists.ietf.org>; Sat, 17 Jan 2004 17:37:35 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Ahyew-0007lx-00
	for ipfix-list@mil.doit.wisc.edu; Sat, 17 Jan 2004 16:11:14 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Ahyev-0007ls-00
	for ipfix@net.doit.wisc.edu; Sat, 17 Jan 2004 16:11:14 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0HMBBkC048069
	for <ipfix@net.doit.wisc.edu>; Sat, 17 Jan 2004 23:11:12 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0HMB8CZ048068
	for <ipfix@net.doit.wisc.edu>; Sat, 17 Jan 2004 23:11:08 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0HMB8kA048066; Sat, 17 Jan 2004 23:11:08 +0100 (CET)
Received: from [10.1.1.26] (dial02.office [10.1.1.26])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 9FC10FACEC; Sat, 17 Jan 2004 23:11:05 +0100 (CET)
Date: Sat, 17 Jan 2004 23:11:05 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Re: IESG comments on: draft-ietf-ipfix-reqs-13.txt
Message-ID: <2147483647.1074381065@[10.1.1.26]>
In-Reply-To: <2147483647.1074295821@[10.1.1.26]>
References:  <2147483647.1074295821@[10.1.1.26]>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Bert,

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

Thanks,

    Juergen

--On 16.01.2004 23:30 Uhr +0100 Juergen Quittek wrote:

> 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        quittek@ccrle.nec.de        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.

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

>>

[...]

>> 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."
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Sat Jan 17 17:47:31 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14789
	for <ipfix-archive@lists.ietf.org>; Sat, 17 Jan 2004 17:47:30 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AhysO-0000Ky-00
	for ipfix-list@mil.doit.wisc.edu; Sat, 17 Jan 2004 16:25:08 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AhysM-0000Ks-00
	for ipfix@net.doit.wisc.edu; Sat, 17 Jan 2004 16:25:07 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0HMP4kC048185
	for <ipfix@net.doit.wisc.edu>; Sat, 17 Jan 2004 23:25:05 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0HMP0WV048170
	for <ipfix@net.doit.wisc.edu>; Sat, 17 Jan 2004 23:25:00 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0HMOxkA048168; Sat, 17 Jan 2004 23:25:00 +0100 (CET)
Received: from [10.1.1.26] (dial02.office [10.1.1.26])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id DA395FACFD; Sat, 17 Jan 2004 23:24:55 +0100 (CET)
Date: Sat, 17 Jan 2004 23:24:54 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: ipfix@net.doit.wisc.edu
Cc: bwijnen@lucent.com
Subject: [ipfix] [new IPFIX requirements draft
Message-ID: <2147483647.1074381894@[10.1.1.26]>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dear all,

Below please find the list of changes from version -13 to the new
version -14 of the IPFIX requirements draft.

Until it gets posted you can cpreview it at

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

Cheers,

    Juergen
-- 
Juergen Quittek        quittek@ccrle.nec.de        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


=========================
IPFIX Requirements Issues
=========================


========================================================================
22. IPR boilerplate missing
========================================================================
Problem Description:
------------------------------------------------------------------------
There is no IPR boilerplate.

raised by Ned Fred
========================================================================
Suggested solution:
------------------------------------------------------------------------
add new Section 16:

   "16.  IPR Notices

      The IETF takes no position regarding the validity or scope of any
      intellectual property or other rights that might be claimed to
      pertain to the implementation or use of the technology described in
      this document or the extent to which any license under such rights
      might or might not be available; neither does it represent that it
      has made any effort to identify any such rights.  Information on the
      IETF's procedures with respect to rights in standards-track and
      standards-related documentation can be found in BCP-11.  Copies of
      claims of rights made available for publication and any assurances of
      licenses to be made available, or the result of an attempt made to
      obtain a general license or permission for the use of such
      proprietary rights by implementors or users of this specification can
      be obtained from the IETF Secretariat.

      The IETF invites any interested party to bring to its attention any
      copyrights, patents or patent applications, or other proprietary
      rights which may cover technology that may be required to practice
      this standard.  Please address the information to the IETF Executive
      Director."
========================================================================
Status: solution committed
========================================================================



========================================================================
23. Section on metering process requirement for encrypted packets
========================================================================
Problem Description:
------------------------------------------------------------------------
Section 4.6 explains that some of the requirements listed in Sections
4.1 - 4.5 do not apply to encrypted packets. This should be mentioned
before describing the requirements in Sections 4.1 - 4.5.

raised by Ted Hardie and Russ Housley
========================================================================
Suggested solution:
------------------------------------------------------------------------
move Section 4.6 up to become Section 4.1
========================================================================
Status: solution committed
========================================================================



========================================================================
24. Term "flow specific data" in Section 6.3.3 unclear
========================================================================
Problem Description:
------------------------------------------------------------------------
Section 6.3.3 requires integrity and authenticity for "IPFIX data"
but confidentiality is only required for flow-specific data.  This
might lead to confusion.

raised by Russ Housley
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace "flow specific data" by "IPFIX data".
========================================================================
Status: solution committed
========================================================================



========================================================================
25. Wrong confidentiality requirement in appendix
========================================================================
Problem Description:
------------------------------------------------------------------------
The appendix states the confidentiality requirement for application
Attack/Intrusion Detection as "SHOULD".  This does not match with
the arguments given in the Security Considerations.

raised by Russ Housley
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace "S" by "M" for entry "6.3.3 Confidentiality" in the appendix
========================================================================
Status: solution committed
========================================================================



========================================================================
26. Badly structured Section 4.2
========================================================================
Problem Description:
------------------------------------------------------------------------
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.

raised by Russ Housley and Margaret Wasserman
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace

  "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."
========================================================================
Status: solution committed
========================================================================



========================================================================
27. Confusion about significance of MUST, SHOULD, and MAY
========================================================================
Problem Description:
------------------------------------------------------------------------
Margaret Wasserman:
"I don't understand the section that discusses the significance
of how the terms MUST, SHOULD or MAY are used in this document."
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace confusing 'MANDATORY' by 'REQUIRED' in section 1, paragraph 3
and section 3, paragraph 3.
========================================================================
Status: solution committed
========================================================================



========================================================================
28. Confusion about significance of MUST, SHOULD, and MAY
========================================================================
Problem Description:
------------------------------------------------------------------------
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.

raised by Margaret Wasserman
========================================================================
Suggested solution:
------------------------------------------------------------------------
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.
========================================================================
Status: no document change required
========================================================================



========================================================================
29. IPv6 Flow ID required for distinguishing flows?
========================================================================
Problem Description:
------------------------------------------------------------------------
Shouldn't you be able to identify a flow based on the IPv6
Flow ID?

raised by Margaret Wasserman
========================================================================
Suggested solution:
------------------------------------------------------------------------
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.
========================================================================
Status: no document change required
========================================================================



========================================================================
30. Why DSCP and not full traffic class
========================================================================
Problem Description:
------------------------------------------------------------------------
Why do we want to be able to identify flows based on the DSCP,
but not the full traffic class?

raised by Margaret Wasserman
========================================================================
Suggested solution:
------------------------------------------------------------------------
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. Note that
not having a requirement does not exclude implementing it.
========================================================================
Status: no document change required
========================================================================




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 19 05:53:05 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11699
	for <ipfix-archive@lists.ietf.org>; Mon, 19 Jan 2004 05:53:05 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AiWcn-0004AI-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jan 2004 04:27:17 -0600
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AiWcm-0004AC-00
	for ipfix@net.doit.wisc.edu; Mon, 19 Jan 2004 04:27:16 -0600
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0JAR6O00387
	for <ipfix@net.doit.wisc.edu>; Mon, 19 Jan 2004 04:27:07 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <C6W60188>; Mon, 19 Jan 2004 11:26:45 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550350A460@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Juergen Quittek <quittek@ccrle.nec.de>,
        "Wijnen, Bert (Bert)"
	 <bwijnen@lucent.com>, ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Re: IESG comments on: draft-ietf-ipfix-reqs-13.txt
Date: Mon, 19 Jan 2004 11:26:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Propose new text (By Juergen):

> >
> >   "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."
> >

s/than IP version/than one IP version/ ??

Bert 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 19 08:14:21 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15457
	for <ipfix-archive@lists.ietf.org>; Mon, 19 Jan 2004 08:14:21 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AiZ4P-0001Dv-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jan 2004 07:03:57 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AiZ4O-0001Dm-00
	for ipfix@net.doit.wisc.edu; Mon, 19 Jan 2004 07:03:56 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0JD3pkE000774
	for <ipfix@net.doit.wisc.edu>; Mon, 19 Jan 2004 14:03:52 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0JD2Abb000697
	for <ipfix@net.doit.wisc.edu>; Mon, 19 Jan 2004 14:02:10 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0JD29kA000694; Mon, 19 Jan 2004 14:02:10 +0100 (CET)
Received: from [10.1.1.171] (n-quittek.office [10.1.1.171])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id D7444F582F; Mon, 19 Jan 2004 14:02:07 +0100 (CET)
Date: Mon, 19 Jan 2004 14:02:10 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Re: IESG comments on: draft-ietf-ipfix-reqs-13.txt
Message-ID: <2147483647.1074520930@[10.1.1.171]>
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550350A460@nl0006exch001u.nl.lucent.com>
References:  <7D5D48D2CAA3D84C813F5B154F43B1550350A460@nl0006exch001u.nl.lucent.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Bert,

Of course. This is a typo.  I fixed quickly on the ftp server.
Let's hope it was in time before the file was downloaded to the
I-D repository.

Thanks,

    Juergen


--On 19.01.2004 11:26 Uhr +0100 Wijnen, Bert (Bert) wrote:

> Propose new text (By Juergen):
>
>> >
>> >   "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."
>> >
>
> s/than IP version/than one IP version/ ??
>
> Bert
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 19 09:45:40 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18285
	for <ipfix-archive@lists.ietf.org>; Mon, 19 Jan 2004 09:45:35 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AiaS4-0003WE-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jan 2004 08:32:28 -0600
Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AiaS3-0003W8-00
	for ipfix@net.doit.wisc.edu; Mon, 19 Jan 2004 08:32:27 -0600
Received: from cisco.com (ams-clip-vpn-dhcp4135.cisco.com [10.61.80.38])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i0JESN703692;
	Mon, 19 Jan 2004 15:28:24 +0100 (CET)
Message-ID: <400BE986.2040204@cisco.com>
Date: Mon, 19 Jan 2004 15:28:22 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: "Meyer, Jeffrey D (http://usage.fc.hp.c)" <jeff.meyer2@hp.com>,
        "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Option templates issues - Consensus?
References: <A747B346BDCCAB45831C24F0CD7C7F09177D68@cacexc03.americas.cpqcorp.net> <3F1ADFD2-44A1-11D8-BCCB-000A95DA1C38@eng.oar.net>
In-Reply-To: <3F1ADFD2-44A1-11D8-BCCB-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Mark Fullmer wrote:

> I think that's where we're at.  Ganesh had suggested the extensible 
> header
> idea after my proposal for using one of the unused FlowSet ID's.
>
> Benoit have discussed this offline and (I think) we're both leaning 
> towards
> using the existing mechanism with FlowSet ID's.  The only real change
> this may mean for IPFIX is a better term than "FlowSet". 

Yes we are.

Regards, Benoit.

>
>
> mark
>
> On Jan 9, 2004, at 5:57 PM, Meyer, Jeffrey D (http://usage.fc.hp.c) 
> wrote:
>
>>   The mechanism for adding extensions would seem to be based on the 
>> reserved range of 0-255 for templateId's.  Currently 0 and 1
>>   are used for flow templates and option templates.  Flow data and 
>> option data are distinguished solely based on previous id assignments
>>   by the respective templates.
>>  
>>   So I guess the proposal would be a hello message or other header 
>> extensions would utilize other values in the range 2-255.  Is this
>>   correct?
>>  
>> Regards,
>>  
>>   Jeff Meyer
>> -----Original Message-----
>> From:Benoit Claise [mailto:bclaise@cisco.com]
>> Sent:Thursday, January 08, 2004 4:19 AM
>> To:Meyer, Jeffrey D (http://usage.fc.hp.c)
>> Cc:Mark Fullmer; 'Ipfix Wg' (E-mail)
>> Subject:Re: [ipfix] Option templates issues - Consensus?
>>
>> Hi,
>>
>> In order to progress with the protocol draft... is there a consensus 
>> for the following concepts?
>>
>> There are two issues here
>>
>>   1) How to provide extra information about the flow data and metering
>>      process.
>>
>>   2) How to allow for protocol extensions.
>>
>> 1) How to provide extra information about the flow data and metering 
>> process.
>> Typical example: the meterstats.
>> An option template will be used
>> The protocol draft will specify what the minimal set of data types is 
>> required
>> A new data type (referred to ipfixOption by Jeff) would be used to 
>> identify specific options templates
>> This would help the collector answering the question:
>> switch (ipfixOption)
>>   case METER_STATS
>>     do that.
>>   case ...
>>     do something else.
>>
>> 2) How to allow for protocol extensions.
>> Typical example: hello, exporter ID, authentication, etc...
>> No options template: an extension to the header will be used.
>>
>> Regards, Benoit.
>>
>> Mark,
>>
>>   Not having seen requirements or discussion for "proxies", I'm 
>> having a hard time conceptualizing this new requirement.
>>
>>   Since option template Id's and flow record template Id's are 
>> currently dynamically determined, I guess what you are arguing is 
>> that options should somehow be fixed.
>>
>>   Since a "hello" option has not even been defined to date, and your 
>> use case seems to be centered around reliable failover, I think there 
>> are a lot of tangled concerns going on here.  Could you elaborate a 
>> bit more on this scenario?
>>
>> -- Jeff
>>
>> -----Original Message-----
>> From: Mark Fullmer [mailto:maf@eng.oar.net]
>> Sent: Tuesday, January 06, 2004 10:36 PM
>> To: Meyer, Jeffrey D (http://usage.fc.hp.c)
>> Cc: 'Ipfix Wg' (E-mail)
>> Subject: Re: [ipfix] Option templates issues
>>
>>
>> Consider a proxy.  If the proxy needs to use an option ID to say
>> maintain
>> HELLO's for a reliable fail-over mechanism it will have to pick a
>> template ID
>> that potentially clashes with a future one used by an exporter.  So now
>> a proxy needs to track all inbound template ID's, map them to outbound
>> ID's,
>> and rewrite fields in the messages that refer to the template ID's.
>>
>> mark
>>
>> On Dec 23, 2003, at 2:12 PM, Meyer, Jeffrey D (http://usage.fc.hp.c)
>> wrote:
>>
>>
>> Mark,
>>
>>   Agreed, it is a choice, and both will work, it is a questions of
>> anticipated extensibility.  Fewer fields in the header and most
>> information elements defined in a consistent manner seems to me to
>> address the approach of "Make it as simple as possible and no
>> simpler".
>>
>>   Since the requirement appears to be addressable with a single
>> mechanism, i.e. a flag distinguishing options from flow elements, and
>> reusing the information modeling, I still don't see the benefit in
>> introducing more mechanisms which need to be implemented and tested on
>> both ends.
>>
>> -- Jeff
>>
>> -----Original Message-----
>> From: Mark Fullmer [mailto:maf@eng.oar.net]
>> Sent: Tuesday, December 23, 2003 10:11 AM
>> To: Meyer, Jeffrey D (http://usage.fc.hp.c)
>> Cc: ipfix@net.doit.wisc.edu; Benoit Claise
>> Subject: Re: [ipfix] Option templates issues
>>
>>
>> There are two issues here
>>
>>    1) How to provide extra information about the flow data and metering
>>       process.
>>
>>    2) How to allow for protocol extensions.
>>
>> If we add a required "key" or "command" field to the options templates
>> then I think what we have will work given the proper text
>> describing what IE's MAY, SHOULD, and MUST be present in an options
>> template with a specific key.  We may want to even have a separate
>> IE namespace for the options....
>>
>> The protocol extension I'm still of the opinion should be handled
>> with an extensible header.  Examples of protocol extensions could be
>>
>>     Reliable fail-over.
>>
>>     Authentication.
>>
>>     The optional time stamp for the split-time model.
>>
>>     Hooks for proxies.
>>
>>     Future unanticipated extensions.
>>
>> And yes, all of this could be stuffed in an options template but the
>> same
>> argument could be used to do away with the protocol header entirely.
>>
>> mark
>>
>>
>> On Dec 22, 2003, at 11:17 AM, Meyer, Jeffrey D (http://usage.fc.hp.c)
>> wrote:
>>
>>
>> Hi,
>>
>>   Again, I'd point out, that as Benoit indicates, there are likely to
>> be different things we want to send as "options".
>>
>>   Rather than inventing an entirely new model, just make option a
>> flag on the template and REUSE what we already have for data records.
>> It's that simple!
>>
>> -- Jeff
>>
>> -----Original Message-----
>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
>> Behalf
>> Of Benoit Claise
>> Sent: Monday, December 22, 2003 4:04 AM
>> To: Mark Fullmer
>> Cc: ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] Option templates issues
>>
>>
>> Mark,
>>
>> [sorry for the delay, i've been absent from the list for a while]
>>
>> I understand the concern but let me ask a few questions.
>> What if the metering process can't "meter" one of them? Ex: flows not
>> exported due to resource starvation
>> What if we would like to export some extra data types? Ex: IPv6
>> packets
>> and bytes dropped
>> So what if the METERSTAT struct is slightly modified?
>>
>> Ganesh had a good point I think:
>>     If the group can come up with fixed structs that you mentioned
>> below,
>>     then I think what you propose can be adopted.
>>
>> Aren't we going to spend a long time to determine what MUST be
>> exported
>> in this/those structure(s)?
>> What you defined in your METERSTAT makes perfectly from a collector
>> point of view but will not always be possible to collect on the
>> exporter?
>> And it does perfectly sense now, but what about in 1 year? So would we
>> have a new data type with a new slightly different structure?
>>
>> I'm just wondering what we should say in the protocol draft:
>>     1. SHOULD export a METERSTAT data type(as described in your
>> email)?
>> What if one data type can't be exported, we don't send any metering
>> stats "message"?
>>     2. MUST export a metering statistics Options Templates that SHOULD
>> contain lost_flows, lost_flows_pkts, lost_flows_bytes, lost_pkts,
>> lost_bytes, time.
>>     3. MUST export a metering statistics Options Templates that MUST
>> contain X, Y, and SHOULD contain Z
>>     4. MUST export a metering statistics Options Templates that
>> contain
>> at least X, Y
>>
>> Actually, I think the flexibility of the Options Template is
>> benefitial
>> for any data types.
>>
>> Now, this is a different story for the Hello, Failover, etc... types
>> of
>> messages that you spoke about, as the goal is totally different!
>>
>> Regards, Benoit.
>>
>>
>> I'd like to propose an alternative mechanism for sending auxiliary
>> data such
>> as time synch messages, protocol hellos (needed for fail-over),
>> metering
>> process loss statistics (ie packets/flows lost due to resource
>> starvation),
>> etc.
>>
>> The existing framework allows "other" data to be sent in options
>> templates.
>> Take for example a metering process stat message.  Lets say the
>> metering
>> process will periodically report statistics such as
>>
>>   struct METERSTAT {
>>     u_int32_t lost_flows;       /* flows not exported due to resource
>> starvation */
>>     u_int32_t lost_flows_pkts;  /* packets in the lost flows */
>>     u_int32_t lost_flows_bytes; /* bytes in the lost flows */
>>     u_int32_t lost_pkts;   /* packets dropped by metering process */
>>     u_int32_t lost_bytes;  /* bytes dropped by metering process */
>>     time_t    now;         /* when this record was generated */
>>   };
>>
>>   The question becomes how to encode this with an options template.
>>
>>   Each field in the record could have a type (6 types), then the
>> options template
>>   would list each of the 6 types.  The problem here is during
>> decoding.  What
>>   will the collector do if only 5 of these items show up.  The packet
>> decode
>>   process is also not very straightforward when just data is sent
>> (other option
>>   fields could be in the same template) because it will have to
>> figure
>> out
>>   what to do based on the field type and there's no way to group
>> fields.
>>
>>   The other option is to call METERSTAT a type (of length 24).  Now
>> the
>>   decode process can key off of the type and all the fields will
>> always be
>>   there because METERSTAT is fixed and defined in the protocol
>> document just
>>   like other fields like PACKETS, BYTES, PROTOCOL, etc.  The issue I
>> have here
>>   is why are we bothering with a template/data model for this.  Why
>> not just
>>   use traditional TLV's.
>>
>>   So what I'd like to see (I think) is to take one of the existing
>> reserved
>>   flowset ID's, lets say 3 and use it for generic TLV data encodings.
>> Then
>>   define structured data in the protocol such as METERSTAT.  IMHO
>> this
>> allows us
>>   to address a number of other issues including how to add HELLO's
>> for
>> the
>>   (optional) reliable failover, how to add aux flags like "this is
>> potentially
>>   a duplicate PDU because I failed over", etc.
>>
>>   The TLV encodings would only be used for the low bit-rate protocol
>> messages,
>>   NOT the high bandwidth flow data.  I'm also not proposing the
>> option
>> templates
>>   go away, just that we use a more traditional method for encoding
>> the
>> non flow
>>   data.
>>
>> mark
>>
>>
>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>>
>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 19 11:39:35 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25189
	for <ipfix-archive@lists.ietf.org>; Mon, 19 Jan 2004 11:39:34 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Aic3C-0006E8-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jan 2004 10:14:54 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Aic3A-0006E0-00
	for ipfix@net.doit.wisc.edu; Mon, 19 Jan 2004 10:14:52 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 19 Jan 2004 17:15:32 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i0JGESkl028342
	for <ipfix@net.doit.wisc.edu>; Mon, 19 Jan 2004 17:14:28 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp173.cisco.com [10.61.64.173])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA04331;
	Mon, 19 Jan 2004 16:14:47 GMT
Message-ID: <400C0277.3040605@cisco.com>
Date: Mon, 19 Jan 2004 16:14:47 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] [Fwd: Re: IPFIX protcol draft security section]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


I did some work on the security section written
by Mark Fulmer for the IPFIX protocol draft.

We can take the bit about transport pathology out
if it is too controversial, but it occured to me, as
I was thinking this out, that congestion is not
the only consideration when it comes to IPFIX
transport.

- Stewart


Security Section
----------------

Because IPFIX can be used to collect billing information and
network forensics, confusing or blinding IPFIX must be seen
as a prime objective during a sophisticated network attack.

If an attacker is in a position to inject false messages into
an IPFIX message stream this will allow them to send forged
flow records, options, or templates.  Forged templates may
impair the collectors ability to process any further flow records.
Forged flow records would have a direct effect on the application
using the flows, for example a billing system may generate
incorrect billing information.  Forged options may be able to
alter the meaning of flow records, for example if the sample
rate is changed.

The IPFIX messages themselves may contain information of value
to an attacker, and thus care must be taken to confine their
visibility to authorized users.

The IPFIX protocol runs over any IETF specified transport protocol
and hence the messages sent to the collector by the observer
may be secured using IPsec. However this does not address all of
the security issues in an IPsec deployment.

IPsec Profile
-------------

To secure messages between the observer and the collector
an IPFIX implementation MAY use IPsec. To ensure inter-working
between observers and collectors from different vendors,
the following IPsec profile MUST be supported. This profile
is derived from [USEIPSEC]

Selectors
---------

IPFIX runs between manually configured pairs of hosts on
the following transport ports (TBD).  The appropriate
selector would be the IPFIX collector for that port only.
Note that if the observer is a router, the "loopback address"
is almost certainly the address to use.

Mode
----

IPsec MUST be run in transport mode, and MAY use either the
Authentication Header (AH) [RFC2402] or the Security Protocol
(ESP) [RFC2406] depending on the perceived level of threat
to the IPSEC message content. The information being communicated
may be confidential, in which case ESP MUST used. If ESP is
used, the sender's IP address MUST be checked against the
IP address asserted in the key management exchange.

The AH MUST be supported by an IPFIX implementation of IPsec.

Key Management
--------------

In most network, manual key management will be sufficient,
and reduces the complexity of the observer, albeit at a
cost of greater configuration complexity. Manual key management
MUST be supported. If a replay attack is considered likely,
an automated key management the IKE key managent system SHOULD
be used.

Security Policy
---------------
Connections should be accepted only from the designated peer.

Authentication
--------------
Given the number of IPFIX capable routers likely to be
deployed by a large ISPs, it is likely that shared key
mechanisms are inadequate.  Consequently, where an automated
key management system is used, certificate-based IKE SHOULD
be supported.  Whatever scheme is used, it must tie back to a
source IP address in some fashion.

Availability
------------
It is accepted that IPsec will not be universally available
in IPFIX observers, and that where it is available, there may
be issues of throughput, which may itself raise security
issues. In such circumstances the other security measures
described in this draft provide some threat mitigation.

Network Architecture
--------------------

Ideally messages from the IPFIX observer to the IPFIX collector
should travel over a dedicated network such as a dedicated
point to point link. In all cases, useful protection is gained
by allocating observer and collector IP addresses from ranges
that are excluded from use for user traffic. By sending the
IPFIX messages over a dedicated network, message IPFIX message
loss induced by user traffic congestion is minimized. However
an attacker may trigger the generation of excessive IPFIX
messages, and to avoid information loss during such an attack
the IPFIX network must be adequately sized.

The use of a dedicated network also prevents the IPFIX
messages from being inspected by an attacker.

When IPsec is not an option
---------------------------
When IPsec is not an option, perhaps due to performance issues,
but some level of protection against an insertion attack is
required, it is recommended that a 64 bit cookie [L2TPv3] be
included as a mandatory element within all messages.

[Note if we follow this approach, we will need to do some work
on the protocol itself - SB]

Without IPsec the IPFIX collector has no means to authenticate
an exporter other than the exporters Source IP address. Where
large numbers of observers, proxies and collectors are used
in a network, it may be tempting for the administrator to
not impose source IP address restrictions, this leaves the
collector open to reception of invalid flows. The use
praxes using an open collector is therefore to be deprecated.

Transport Issues
----------------

Some IPFIX security issues are dependent on the transport.
For example with UDP unsolicited messages may be received
and not detected, with a modern implementation of TCP with
good ISN randomization [XXX-REFERENCE] or SCTP these types
of attacks are much more difficult without an attacker
with access to snoop the packet flow.
[XXX-SCTP-BLIND-SPOOFING-REFERENCE]

An attacker may take advantage of the pathology of the
transport protocol or its common implementations to
mount and attack on IPFIX. This might be either as
an assault on IPFIX in its own right or intended to
blind IPFIX to prevent the recording of network forensics
as part of another attack.

Under conditions where the attacker saturated IPFIX, for
example by  initiating the generating enormous numbers
of short lived flows, the behavior of the IPFIX transport
would determine the amount of evidence that was recorded.

If the transport were UDP, then under network overload
conditions IPFIX would reduce to a form or sampled Netflow.
This means that the attacked could never be quite sure
that IPFIX was blinded, and that they may hence be leaving
forensics.

If the transport were TCP, then the flow to the collector
would back off due to congestion discard and eventually stall
blinding the IPFIX system. An attack could then proceed
without further observation. The extent and duration of the
blindness would depend on the detail of the TCP implementation.

SCTP-PR will have a different pathology under such a
saturation attack. Stale data at the head of the queue will
get flushed giving some visibility of the attack.

Whilst the use of a congestion aware transport protocol is
highly desirable to protect the network from overload by
excessive IPFIX traffic, this is exactly wrong behavior
when IPFIX is being to diagnose a DoS attack, or an attack
proceeding under cover of a DoS attack. Under these circumstance
you want the IPFIX transport needs to be congestion neutral
(as is UDP), or congestion aggressive.

Logging an IPFIX Attack
-----------------------

IPFIX has a sequence number which increases with each message.  A
collector may detect out of sequence, dropped, or duplicate messages
by tracking the sequence number.  A collector SHOULD provide a logging
mechanism for tracking out of sequence messages.  Such out of sequence
messages may be due to congestion on the network link between the
exporter and collector, collector resource exhaustion where it can not
process the messages at their arrival rate, exporter resource exhaustion
where it can not transmit messages at their creation rate, out of order
packet reception, duplicate packet reception, an exporting process reset,
or an attacker injecting false messages.

Refs to be cleaned up
---------------------

[USEIPSEC] draft-bellovin-useipsec-02.txt
[L2TPv3] draft-ietf-l2tpext-l2tp-base-11.txt








--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 19 12:50:53 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29713
	for <ipfix-archive@lists.ietf.org>; Mon, 19 Jan 2004 12:50:53 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AidJa-0000qN-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jan 2004 11:35:54 -0600
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AidJZ-0000qE-00
	for ipfix@net.doit.wisc.edu; Mon, 19 Jan 2004 11:35:53 -0600
Received: from fokus.fraunhofer.de (dhcp226 [195.37.78.226])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i0JHZjL16193;
	Mon, 19 Jan 2004 18:35:46 +0100 (MET)
Message-ID: <400C14DC.9000902@fokus.fraunhofer.de>
Date: Mon, 19 Jan 2004 18:33:16 +0100
From: Sebastian Zander <zander@fokus.fraunhofer.de>
Organization: Fraunhofer FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: stbryant@cisco.com
CC: "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [Fwd: Re: IPFIX protcol draft security section]
References: <400C0277.3040605@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Some comments. First some general and the rest interspersed.

- "Observer" should be changed to exporter (or exporting process)
- We could/should add the use of TLS

Stewart Bryant wrote:
> 
> I did some work on the security section written
> by Mark Fulmer for the IPFIX protocol draft.
> 
> We can take the bit about transport pathology out
> if it is too controversial, but it occured to me, as
> I was thinking this out, that congestion is not
> the only consideration when it comes to IPFIX
> transport.
> 
> - Stewart
> 
> 
> Security Section
> ----------------
> 
> Because IPFIX can be used to collect billing information and
> network forensics, confusing or blinding IPFIX must be seen
> as a prime objective during a sophisticated network attack.
> 
> If an attacker is in a position to inject false messages into
> an IPFIX message stream this will allow them to send forged
> flow records, options, or templates.  Forged templates may
> impair the collectors ability to process any further flow records.
> Forged flow records would have a direct effect on the application
> using the flows, for example a billing system may generate
> incorrect billing information.  Forged options may be able to
> alter the meaning of flow records, for example if the sample
> rate is changed.
> 
> The IPFIX messages themselves may contain information of value
> to an attacker, and thus care must be taken to confine their
> visibility to authorized users.
> 
> The IPFIX protocol runs over any IETF specified transport protocol

The IPFIX protocol runs over IP and ...

> and hence the messages sent to the collector by the observer
> may be secured using IPsec. However this does not address all of
> the security issues in an IPsec deployment.
> 
> IPsec Profile
> -------------
> 
> To secure messages between the observer and the collector
> an IPFIX implementation MAY use IPsec. To ensure inter-working
> between observers and collectors from different vendors,
> the following IPsec profile MUST be supported. This profile
> is derived from [USEIPSEC]
> 
> Selectors
> ---------
> 
> IPFIX runs between manually configured pairs of hosts on
> the following transport ports (TBD).  The appropriate
> selector would be the IPFIX collector for that port only.

selector would be exporter collector pairs and port number

> Note that if the observer is a router, the "loopback address"
> is almost certainly the address to use.

what does that mean?

> Mode
> ----
> 
> IPsec MUST be run in transport mode, and MAY use either the
> Authentication Header (AH) [RFC2402] or the Security Protocol
> (ESP) [RFC2406] depending on the perceived level of threat
> to the IPSEC message content. The information being communicated
> may be confidential, in which case ESP MUST used. If ESP is
> used, the sender's IP address MUST be checked against the
> IP address asserted in the key management exchange.
> 
> The AH MUST be supported by an IPFIX implementation of IPsec.

MAY either use AH or AH+ESP. AH MUST be used if authentication
is required. ESP must be used if confidentiality is required.
If somebody requires confidentiality and don't needs IP header
auth then only ESP could be used but I think this not the usual
case.


> Key Management
> --------------
> 
> In most network, manual key management will be sufficient,
> and reduces the complexity of the observer, albeit at a
> cost of greater configuration complexity. Manual key management
> MUST be supported. If a replay attack is considered likely,
> an automated key management the IKE key managent system SHOULD
> be used.
> 
> Security Policy
> ---------------
> Connections should be accepted only from the designated peer.
> 
> Authentication
> --------------
> Given the number of IPFIX capable routers likely to be
> deployed by a large ISPs, it is likely that shared key
> mechanisms are inadequate.  Consequently, where an automated
> key management system is used, certificate-based IKE SHOULD
> be supported.  Whatever scheme is used, it must tie back to a
> source IP address in some fashion.
> 
> Availability
> ------------
> It is accepted that IPsec will not be universally available
> in IPFIX observers, and that where it is available, there may
> be issues of throughput, which may itself raise security
> issues. In such circumstances the other security measures
> described in this draft provide some threat mitigation.
> 
> Network Architecture
> --------------------
> 
> Ideally messages from the IPFIX observer to the IPFIX collector
> should travel over a dedicated network such as a dedicated
> point to point link. In all cases, useful protection is gained
> by allocating observer and collector IP addresses from ranges
> that are excluded from use for user traffic. By sending the

why is that?

> IPFIX messages over a dedicated network, message IPFIX message
> loss induced by user traffic congestion is minimized. However

minimized to 0 I guess.

> an attacker may trigger the generation of excessive IPFIX
> messages, and to avoid information loss during such an attack
> the IPFIX network must be adequately sized.
> 
> The use of a dedicated network also prevents the IPFIX
> messages from being inspected by an attacker.

Presuming complete physical security which may be easy or not
so easy to achieve

> When IPsec is not an option
> ---------------------------
> When IPsec is not an option, perhaps due to performance issues,
> but some level of protection against an insertion attack is
> required, it is recommended that a 64 bit cookie [L2TPv3] be
> included as a mandatory element within all messages.
> 
> [Note if we follow this approach, we will need to do some work
> on the protocol itself - SB]
> 
> Without IPsec the IPFIX collector has no means to authenticate
> an exporter other than the exporters Source IP address. Where

which can be spoofed

> large numbers of observers, proxies and collectors are used
> in a network, it may be tempting for the administrator to
> not impose source IP address restrictions, this leaves the
> collector open to reception of invalid flows. The use
> praxes using an open collector is therefore to be deprecated.
> 
> Transport Issues
> ----------------
> 
> Some IPFIX security issues are dependent on the transport.
> For example with UDP unsolicited messages may be received
> and not detected, with a modern implementation of TCP with
> good ISN randomization [XXX-REFERENCE] or SCTP these types
> of attacks are much more difficult without an attacker
> with access to snoop the packet flow.
> [XXX-SCTP-BLIND-SPOOFING-REFERENCE]

Wouldn't the IPFIX seq number be sufficient in case of UDP?
Maybe it would need proper randomization...

> An attacker may take advantage of the pathology of the
> transport protocol or its common implementations to
> mount and attack on IPFIX. This might be either as
> an assault on IPFIX in its own right or intended to
> blind IPFIX to prevent the recording of network forensics
> as part of another attack.
> 
> Under conditions where the attacker saturated IPFIX, for
> example by  initiating the generating enormous numbers
> of short lived flows, the behavior of the IPFIX transport
> would determine the amount of evidence that was recorded.
> 
> If the transport were UDP, then under network overload
> conditions IPFIX would reduce to a form or sampled Netflow.
> This means that the attacked could never be quite sure
> that IPFIX was blinded, and that they may hence be leaving
> forensics.
> 
> If the transport were TCP, then the flow to the collector
> would back off due to congestion discard and eventually stall
> blinding the IPFIX system. An attack could then proceed
> without further observation. The extent and duration of the
> blindness would depend on the detail of the TCP implementation.
> 
> SCTP-PR will have a different pathology under such a
> saturation attack. Stale data at the head of the queue will
> get flushed giving some visibility of the attack.
> 
> Whilst the use of a congestion aware transport protocol is
> highly desirable to protect the network from overload by
> excessive IPFIX traffic, this is exactly wrong behavior
> when IPFIX is being to diagnose a DoS attack, or an attack
> proceeding under cover of a DoS attack. Under these circumstance
> you want the IPFIX transport needs to be congestion neutral
> (as is UDP), or congestion aggressive.

But on the other hand if UDP is used an attacker might be able to
saturate the separate network and therefore potentially blinding
more than one observation point.

> Logging an IPFIX Attack
> -----------------------
> 
> IPFIX has a sequence number which increases with each message.  A
> collector may detect out of sequence, dropped, or duplicate messages
> by tracking the sequence number.  A collector SHOULD provide a logging
> mechanism for tracking out of sequence messages.  Such out of sequence
> messages may be due to congestion on the network link between the
> exporter and collector, collector resource exhaustion where it can not
> process the messages at their arrival rate, exporter resource exhaustion
> where it can not transmit messages at their creation rate, out of order
> packet reception, duplicate packet reception, an exporting process reset,
> or an attacker injecting false messages.
> 
> Refs to be cleaned up
> ---------------------
> 
> [USEIPSEC] draft-bellovin-useipsec-02.txt
> [L2TPv3] draft-ietf-l2tpext-l2tp-base-11.txt
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 


-- 
Sebastian Zander                         E-mail: zander@fokus.fraunhofer.de
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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 19 15:42:01 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08027
	for <ipfix-archive@lists.ietf.org>; Mon, 19 Jan 2004 15:42:01 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Aifqy-0005AK-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jan 2004 14:18:32 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1Aifqx-0005AE-00
	for ipfix@net.doit.wisc.edu; Mon, 19 Jan 2004 14:18:31 -0600
Received: (qmail 64683 invoked by alias); 19 Jan 2004 20:18:30 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 19 Jan 2004 20:18:30 -0000
In-Reply-To: <4003D9BB.10709@cisco.com>
References: <0F408853-44B1-11D8-BCCB-000A95DA1C38@eng.oar.net> <4002790B.4020607@cisco.com> <32938C46-4584-11D8-BCCB-000A95DA1C38@eng.oar.net> <4003D9BB.10709@cisco.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <A4B69AF0-4ABC-11D8-9ACD-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>,
        Benoit Claise <bclaise@cisco.com>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] protocol security section
Date: Mon, 19 Jan 2004 15:18:28 -0500
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

I'm not sure a preconfigured cookie is anything more than a password....

If a random cookie were to be signaled over a TCP or SCTP connection,
for example with templates and options, then use UDP with a cookie in
the IPFIX message for the flow data this would mitigate blind insertion
attacks when using UDP as the transport.  This requires that we use TCP
or SCTP as the control channel when using UDP, which happens to address
a number of other issues at the same time.

--
mark

On Jan 13, 2004, at 6:42 AM, Stewart Bryant wrote:

>
>
> Mark Fullmer wrote:
>> On Jan 12, 2004, at 5:38 AM, Stewart Bryant wrote:
>>>
>>> In <draft-ietf-l2tpext-l2tp-base-11.txt> which also has issues with
>>> IPsec being too heavy weight, it is proposed that blind insertion
>>> attacks be addressed through the use of a 64 bit cookie (a 64 bit
>>> randomly chosen password common to each end) is used. I am not sure
>>> whether this is going to be blessed by the IESG, but it would make
>>> sense is we used exactly the same approach and exactly the same
>>> argument (ie import their data plane security text). That way
>>> either both get accepted, or a common work item addresses the 
>>> shortfall.
>> How does the collector know the cookie is valid?
>
> In the L2TPv3 case, they are either reconfigured at both ends, or
> signalled at session startup.
>
> We could clearly preconfigure them, or we could exchange them over
> a secure channel along with the template.
>
> Stewart
>
>> -- 
>> mark
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 19 18:10:16 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14163
	for <ipfix-archive@lists.ietf.org>; Mon, 19 Jan 2004 18:10:16 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AiiO5-0007QY-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jan 2004 17:00:53 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AiiO4-0007QR-00
	for ipfix@net.doit.wisc.edu; Mon, 19 Jan 2004 17:00:52 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 20 Jan 2004 00:01:36 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i0JN0UiP001658;
	Tue, 20 Jan 2004 00:00:31 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp4219.cisco.com [10.61.80.122])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA20123;
	Mon, 19 Jan 2004 23:00:49 GMT
Message-ID: <400C61A1.8070703@cisco.com>
Date: Mon, 19 Jan 2004 23:00:49 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sebastian Zander <zander@fokus.fraunhofer.de>
CC: "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [Fwd: Re: IPFIX protcol draft security section]
References: <400C0277.3040605@cisco.com> <400C14DC.9000902@fokus.fraunhofer.de>
In-Reply-To: <400C14DC.9000902@fokus.fraunhofer.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Sebastian Zander wrote:

> Some comments. First some general and the rest interspersed.
> 
> - "Observer" should be changed to exporter (or exporting process)
> - We could/should add the use of TLS

TLS?

> 
> Stewart Bryant wrote:
> 
>>
>> I did some work on the security section written
>> by Mark Fulmer for the IPFIX protocol draft.
>>
>> We can take the bit about transport pathology out
>> if it is too controversial, but it occured to me, as
>> I was thinking this out, that congestion is not
>> the only consideration when it comes to IPFIX
>> transport.
>>
>> - Stewart
>>
>>
>> Security Section
>> ----------------
>>
>> Because IPFIX can be used to collect billing information and
>> network forensics, confusing or blinding IPFIX must be seen
>> as a prime objective during a sophisticated network attack.
>>
>> If an attacker is in a position to inject false messages into
>> an IPFIX message stream this will allow them to send forged
>> flow records, options, or templates.  Forged templates may
>> impair the collectors ability to process any further flow records.
>> Forged flow records would have a direct effect on the application
>> using the flows, for example a billing system may generate
>> incorrect billing information.  Forged options may be able to
>> alter the meaning of flow records, for example if the sample
>> rate is changed.
>>
>> The IPFIX messages themselves may contain information of value
>> to an attacker, and thus care must be taken to confine their
>> visibility to authorized users.
>>
>> The IPFIX protocol runs over any IETF specified transport protocol
> 
> 
> The IPFIX protocol runs over IP and ...
> 

I was assuming that all IETF specified transports ran over IP.
The only thing that is likely to change this is TCP/MPLS, but
that is not on any WG agendas that I am aware of :)


>> and hence the messages sent to the collector by the observer
>> may be secured using IPsec. However this does not address all of
>> the security issues in an IPsec deployment.
>>
>> IPsec Profile
>> -------------
>>
>> To secure messages between the observer and the collector
>> an IPFIX implementation MAY use IPsec. To ensure inter-working
>> between observers and collectors from different vendors,
>> the following IPsec profile MUST be supported. This profile
>> is derived from [USEIPSEC]
>>

In useipsec the example is a BGP entity on a router, so what
we have here is a lightly edited version of the example.
I would that that IPFIX is quite a close cousin of Steve's
example.

>> Selectors
>> ---------
>>
>> IPFIX runs between manually configured pairs of hosts on
>> the following transport ports (TBD).  The appropriate
>> selector would be the IPFIX collector for that port only.
> 
> 
> selector would be exporter collector pairs and port number

I think that the selection occurs at the server end of the
client server pair, so only one IP address is needed. Does
the exporter normally collect the collector of visa verse?
So it is only one IP address and one port.


> 
>> Note that if the observer is a router, the "loopback address"
>> is almost certainly the address to use.
> 
> 
> what does that mean?
> 

One of the non-interface addresses (because if you use an interafce
address and the interface goes down, so does the session)

>> Mode
>> ----
>>
>> IPsec MUST be run in transport mode, and MAY use either the
>> Authentication Header (AH) [RFC2402] or the Security Protocol
>> (ESP) [RFC2406] depending on the perceived level of threat
>> to the IPSEC message content. The information being communicated
>> may be confidential, in which case ESP MUST used. If ESP is
>> used, the sender's IP address MUST be checked against the
>> IP address asserted in the key management exchange.
>>
>> The AH MUST be supported by an IPFIX implementation of IPsec.
> 
> 
> MAY either use AH or AH+ESP. AH MUST be used if authentication
> is required. ESP must be used if confidentiality is required.
> If somebody requires confidentiality and don't needs IP header
> auth then only ESP could be used but I think this not the usual
> case.
> 

Again I copied the BGP example, and I would have thought that this
was exactly correct. It's a bit late here, but I will double check
in the morning agains Steve's text.

> 
>> Key Management
>> --------------
>>
>> In most network, manual key management will be sufficient,
>> and reduces the complexity of the observer, albeit at a
>> cost of greater configuration complexity. Manual key management
>> MUST be supported. If a replay attack is considered likely,
>> an automated key management the IKE key managent system SHOULD
>> be used.
>>
>> Security Policy
>> ---------------
>> Connections should be accepted only from the designated peer.
>>
>> Authentication
>> --------------
>> Given the number of IPFIX capable routers likely to be
>> deployed by a large ISPs, it is likely that shared key
>> mechanisms are inadequate.  Consequently, where an automated
>> key management system is used, certificate-based IKE SHOULD
>> be supported.  Whatever scheme is used, it must tie back to a
>> source IP address in some fashion.
>>
>> Availability
>> ------------
>> It is accepted that IPsec will not be universally available
>> in IPFIX observers, and that where it is available, there may
>> be issues of throughput, which may itself raise security
>> issues. In such circumstances the other security measures
>> described in this draft provide some threat mitigation.
>>
>> Network Architecture
>> --------------------
>>
>> Ideally messages from the IPFIX observer to the IPFIX collector
>> should travel over a dedicated network such as a dedicated
>> point to point link. In all cases, useful protection is gained
>> by allocating observer and collector IP addresses from ranges
>> that are excluded from use for user traffic. By sending the
> 
> 
> why is that?

So that there is no routing path from a user to the IPFIX pair.

> 
>> IPFIX messages over a dedicated network, message IPFIX message
>> loss induced by user traffic congestion is minimized. However
> 
> 
> minimized to 0 I guess.

No, you could get congestion during an attack on th IPFIX
network depending on the type of attack, it's indensity,
and the capacity of the ipfix network. Now you would expect
it to be zero, but I don't think that you can guarantee it
and therefore should not say so in a security section.

> 
>> an attacker may trigger the generation of excessive IPFIX
>> messages, and to avoid information loss during such an attack
>> the IPFIX network must be adequately sized.
>>
>> The use of a dedicated network also prevents the IPFIX
>> messages from being inspected by an attacker.
> 
> 
> Presuming complete physical security which may be easy or not
> so easy to achieve

But if you could it would. A pt-pt direct link is one example.

> 
>> When IPsec is not an option
>> ---------------------------
>> When IPsec is not an option, perhaps due to performance issues,
>> but some level of protection against an insertion attack is
>> required, it is recommended that a 64 bit cookie [L2TPv3] be
>> included as a mandatory element within all messages.
>>
>> [Note if we follow this approach, we will need to do some work
>> on the protocol itself - SB]
>>
>> Without IPsec the IPFIX collector has no means to authenticate
>> an exporter other than the exporters Source IP address. Where
> 
> 
> which can be spoofed

exactly.
> 
>> large numbers of observers, proxies and collectors are used
>> in a network, it may be tempting for the administrator to
>> not impose source IP address restrictions, this leaves the
>> collector open to reception of invalid flows. The use
>> praxes using an open collector is therefore to be deprecated.
>>
>> Transport Issues
>> ----------------
>>
>> Some IPFIX security issues are dependent on the transport.
>> For example with UDP unsolicited messages may be received
>> and not detected, with a modern implementation of TCP with
>> good ISN randomization [XXX-REFERENCE] or SCTP these types
>> of attacks are much more difficult without an attacker
>> with access to snoop the packet flow.
>> [XXX-SCTP-BLIND-SPOOFING-REFERENCE]
> 
> 
> Wouldn't the IPFIX seq number be sufficient in case of UDP?
> Maybe it would need proper randomization...
> 

It's only 32 bits, see Mark Townsley's L2TP discussion on the
issues of such small sequence spaces. Which remind's me I think
we need some discussion on the sequence number recovery protocol
and its risks.

>> An attacker may take advantage of the pathology of the
>> transport protocol or its common implementations to
>> mount and attack on IPFIX. This might be either as
>> an assault on IPFIX in its own right or intended to
>> blind IPFIX to prevent the recording of network forensics
>> as part of another attack.
>>
>> Under conditions where the attacker saturated IPFIX, for
>> example by  initiating the generating enormous numbers
>> of short lived flows, the behavior of the IPFIX transport
>> would determine the amount of evidence that was recorded.
>>
>> If the transport were UDP, then under network overload
>> conditions IPFIX would reduce to a form or sampled Netflow.
>> This means that the attacked could never be quite sure
>> that IPFIX was blinded, and that they may hence be leaving
>> forensics.
>>
>> If the transport were TCP, then the flow to the collector
>> would back off due to congestion discard and eventually stall
>> blinding the IPFIX system. An attack could then proceed
>> without further observation. The extent and duration of the
>> blindness would depend on the detail of the TCP implementation.
>>
>> SCTP-PR will have a different pathology under such a
>> saturation attack. Stale data at the head of the queue will
>> get flushed giving some visibility of the attack.
>>
>> Whilst the use of a congestion aware transport protocol is
>> highly desirable to protect the network from overload by
>> excessive IPFIX traffic, this is exactly wrong behavior
>> when IPFIX is being to diagnose a DoS attack, or an attack
>> proceeding under cover of a DoS attack. Under these circumstance
>> you want the IPFIX transport needs to be congestion neutral
>> (as is UDP), or congestion aggressive.
> 
> 
> But on the other hand if UDP is used an attacker might be able to
> saturate the separate network and therefore potentially blinding
> more than one observation point.
> 

I still think that it's worse with a congestion aware transport.
If you saturate that network, they all start to back off.

>> Logging an IPFIX Attack
>> -----------------------
>>
>> IPFIX has a sequence number which increases with each message.  A
>> collector may detect out of sequence, dropped, or duplicate messages
>> by tracking the sequence number.  A collector SHOULD provide a logging
>> mechanism for tracking out of sequence messages.  Such out of sequence
>> messages may be due to congestion on the network link between the
>> exporter and collector, collector resource exhaustion where it can not
>> process the messages at their arrival rate, exporter resource exhaustion
>> where it can not transmit messages at their creation rate, out of order
>> packet reception, duplicate packet reception, an exporting process reset,
>> or an attacker injecting false messages.
>>
>> Refs to be cleaned up
>> ---------------------
>>
>> [USEIPSEC] draft-bellovin-useipsec-02.txt
>> [L2TPv3] draft-ietf-l2tpext-l2tp-base-11.txt
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
> 
> 



--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Mon Jan 19 18:21:31 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15217
	for <ipfix-archive@lists.ietf.org>; Mon, 19 Jan 2004 18:21:31 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AiiVL-0007jN-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jan 2004 17:08:23 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AiiVK-0007jH-00
	for ipfix@net.doit.wisc.edu; Mon, 19 Jan 2004 17:08:23 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 20 Jan 2004 00:09:07 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i0JN81PT002986;
	Tue, 20 Jan 2004 00:08:01 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp4219.cisco.com [10.61.80.122])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA20349;
	Mon, 19 Jan 2004 23:08:20 GMT
Message-ID: <400C6364.3020805@cisco.com>
Date: Mon, 19 Jan 2004 23:08:20 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@eng.oar.net>
CC: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>,
        Benoit Claise <bclaise@cisco.com>
Subject: Re: [ipfix] protocol security section
References: <0F408853-44B1-11D8-BCCB-000A95DA1C38@eng.oar.net> <4002790B.4020607@cisco.com> <32938C46-4584-11D8-BCCB-000A95DA1C38@eng.oar.net> <4003D9BB.10709@cisco.com> <A4B69AF0-4ABC-11D8-9ACD-000A95DA1C38@eng.oar.net>
In-Reply-To: <A4B69AF0-4ABC-11D8-9ACD-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Mark Fullmer wrote:

> I'm not sure a preconfigured cookie is anything more than a password....
> 

It's not, and the only reason that I propose it is because

a) A number is more likely to be ransom that a text password
b) There is another IETF WG that is closer to finishing than we are
    that is going to make the argument to the IESG, and it seems
    better to use them as presidence.

> If a random cookie were to be signaled over a TCP or SCTP connection,
> for example with templates and options, then use UDP with a cookie in
> the IPFIX message for the flow data this would mitigate blind insertion
> attacks when using UDP as the transport.  This requires that we use TCP
> or SCTP as the control channel when using UDP, which happens to address
> a number of other issues at the same time.

Puting it in the template is the best way to send it across, and
I agree that there are merits in sending the template over SCTP or
TCP, but I don't think that it MUST use SCTP/TCP.

Stewart

> 
> -- 
> mark
> 
> On Jan 13, 2004, at 6:42 AM, Stewart Bryant wrote:
> 
>>
>>
>> Mark Fullmer wrote:
>>
>>> On Jan 12, 2004, at 5:38 AM, Stewart Bryant wrote:
>>>
>>>>
>>>> In <draft-ietf-l2tpext-l2tp-base-11.txt> which also has issues with
>>>> IPsec being too heavy weight, it is proposed that blind insertion
>>>> attacks be addressed through the use of a 64 bit cookie (a 64 bit
>>>> randomly chosen password common to each end) is used. I am not sure
>>>> whether this is going to be blessed by the IESG, but it would make
>>>> sense is we used exactly the same approach and exactly the same
>>>> argument (ie import their data plane security text). That way
>>>> either both get accepted, or a common work item addresses the 
>>>> shortfall.
>>>
>>> How does the collector know the cookie is valid?
>>
>>
>> In the L2TPv3 case, they are either reconfigured at both ends, or
>> signalled at session startup.
>>
>> We could clearly preconfigure them, or we could exchange them over
>> a secure channel along with the template.
>>
>> Stewart
>>
>>> -- 
>>> mark
>>
>>
>>
>> -- 
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
> 
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 20 12:31:19 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13742
	for <ipfix-archive@lists.ietf.org>; Tue, 20 Jan 2004 12:31:18 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AizIp-00077z-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 20 Jan 2004 11:04:35 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AizIo-00077t-00
	for ipfix@net.doit.wisc.edu; Tue, 20 Jan 2004 11:04:34 -0600
Received: (qmail 70342 invoked by alias); 20 Jan 2004 17:04:33 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 20 Jan 2004 17:04:33 -0000
In-Reply-To: <400C6364.3020805@cisco.com>
References: <0F408853-44B1-11D8-BCCB-000A95DA1C38@eng.oar.net> <4002790B.4020607@cisco.com> <32938C46-4584-11D8-BCCB-000A95DA1C38@eng.oar.net> <4003D9BB.10709@cisco.com> <A4B69AF0-4ABC-11D8-9ACD-000A95DA1C38@eng.oar.net> <400C6364.3020805@cisco.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B738A6D6-4B6A-11D8-8D2E-000A95DA1C38@eng.oar.net>
Content-Transfer-Encoding: 7bit
Cc: "'Ipfix Wg' (E-mail)" <ipfix@net.doit.wisc.edu>,
        Benoit Claise <bclaise@cisco.com>
From: Mark Fullmer <maf@eng.oar.net>
Subject: Re: [ipfix] protocol security section
Date: Tue, 20 Jan 2004 12:04:31 -0500
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Okay.  I'm in favor of a pre-configured cookie.

The random cookie for UDP would solve a different
problem that should probably be handled on its own.

In a nutshell we probably need a random session ID
added if UDP is used on its own.

--
mark

On Jan 19, 2004, at 6:08 PM, Stewart Bryant wrote:

>
>
> Mark Fullmer wrote:
>
>> I'm not sure a preconfigured cookie is anything more than a 
>> password....
>
> It's not, and the only reason that I propose it is because
>
> a) A number is more likely to be ransom that a text password
> b) There is another IETF WG that is closer to finishing than we are
>    that is going to make the argument to the IESG, and it seems
>    better to use them as presidence.
>
>> If a random cookie were to be signaled over a TCP or SCTP connection,
>> for example with templates and options, then use UDP with a cookie in
>> the IPFIX message for the flow data this would mitigate blind 
>> insertion
>> attacks when using UDP as the transport.  This requires that we use 
>> TCP
>> or SCTP as the control channel when using UDP, which happens to 
>> address
>> a number of other issues at the same time.
>
> Puting it in the template is the best way to send it across, and
> I agree that there are merits in sending the template over SCTP or
> TCP, but I don't think that it MUST use SCTP/TCP.
>
> Stewart
>
>> -- 
>> mark
>> On Jan 13, 2004, at 6:42 AM, Stewart Bryant wrote:
>>>
>>>
>>> Mark Fullmer wrote:
>>>
>>>> On Jan 12, 2004, at 5:38 AM, Stewart Bryant wrote:
>>>>
>>>>>
>>>>> In <draft-ietf-l2tpext-l2tp-base-11.txt> which also has issues with
>>>>> IPsec being too heavy weight, it is proposed that blind insertion
>>>>> attacks be addressed through the use of a 64 bit cookie (a 64 bit
>>>>> randomly chosen password common to each end) is used. I am not sure
>>>>> whether this is going to be blessed by the IESG, but it would make
>>>>> sense is we used exactly the same approach and exactly the same
>>>>> argument (ie import their data plane security text). That way
>>>>> either both get accepted, or a common work item addresses the 
>>>>> shortfall.
>>>>
>>>> How does the collector know the cookie is valid?
>>>
>>>
>>> In the L2TPv3 case, they are either reconfigured at both ends, or
>>> signalled at session startup.
>>>
>>> We could clearly preconfigure them, or we could exchange them over
>>> a secure channel along with the template.
>>>
>>> Stewart
>>>
>>>> -- 
>>>> mark
>>>
>>>
>>>
>>> -- 
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>> message body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
> message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
>


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 20 13:41:57 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15565
	for <ipfix-archive@lists.ietf.org>; Tue, 20 Jan 2004 13:41:57 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Aj0fc-0001ro-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 20 Jan 2004 12:32:12 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Aj0fb-0001ri-00
	for ipfix@net.doit.wisc.edu; Tue, 20 Jan 2004 12:32:11 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 20 Jan 2004 19:32:53 +0100
Received: from cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i0KIVmws001516;
	Tue, 20 Jan 2004 19:31:49 +0100 (MET)
Received: from cisco.com (dhcp-rea-gp250-64-103-65-197.cisco.com [64.103.65.197])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA23837;
	Tue, 20 Jan 2004 18:32:08 GMT
Message-ID: <400D7428.1010107@cisco.com>
Date: Tue, 20 Jan 2004 18:32:08 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Fullmer <maf@splintered.net>
CC: Sebastian Zander <zander@fokus.fraunhofer.de>,
        "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [Fwd: Re: IPFIX protcol draft security section]
References: <400C0277.3040605@cisco.com> <400C14DC.9000902@fokus.fraunhofer.de> <400C61A1.8070703@cisco.com> <CDD51F5D-4B73-11D8-BAB4-000A95DA1C38@splintered.net>
In-Reply-To: <CDD51F5D-4B73-11D8-BAB4-000A95DA1C38@splintered.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Mark Fullmer wrote:

> 
> On Jan 19, 2004, at 6:00 PM, Stewart Bryant wrote:
> 
>>
>>
>> Sebastian Zander wrote:
>>
>>>> Some IPFIX security issues are dependent on the transport.
>>>> For example with UDP unsolicited messages may be received
>>>> and not detected, with a modern implementation of TCP with
>>>> good ISN randomization [XXX-REFERENCE] or SCTP these types
>>>> of attacks are much more difficult without an attacker
>>>> with access to snoop the packet flow.
>>>> [XXX-SCTP-BLIND-SPOOFING-REFERENCE]
>>>
>>> Wouldn't the IPFIX seq number be sufficient in case of UDP?
>>> Maybe it would need proper randomization...
>>
>>
>> It's only 32 bits, see Mark Townsley's L2TP discussion on the
>> issues of such small sequence spaces. Which remind's me I think
>> we need some discussion on the sequence number recovery protocol
>> and its risks.
>>
>>
> 
> The problem is more fundamental than this.  How does a collector
> know what would be the ISN?  How does a collector know the difference
> between a new linecard being inserted, thus a new observation domain ID
> (also called Source ID in the draft) with a new sequence number space and
> an attacker picking a random Source ID and spoofing in forged flow data.
> 
> A pre-configured cookie shared by the collector and exporter addresses
> these issues unless the attacker knows the cookie.


We are actually in violent agreement here, a pre-configured
cookie is what we are both advocating (it is how it works in
one of the L2TPv3 modes),  however it is still vulnerable to sniffing.

Stewart




--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 20 14:01:36 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16149
	for <ipfix-archive@lists.ietf.org>; Tue, 20 Jan 2004 14:01:35 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Aj0zh-0002XU-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 20 Jan 2004 12:52:57 -0600
Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Aj0zg-0002XO-00
	for ipfix@net.doit.wisc.edu; Tue, 20 Jan 2004 12:52:56 -0600
Received: from cisco.com (ams-clip-vpn-dhcp4194.cisco.com [10.61.80.97])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i0KIqn711295;
	Tue, 20 Jan 2004 19:52:49 +0100 (CET)
Message-ID: <400D7901.4090000@cisco.com>
Date: Tue, 20 Jan 2004 19:52:49 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ipfix <ipfix@net.doit.wisc.edu>
Subject: [ipfix] draft-ietf-ipfix-protocol-02.txt
Content-Type: multipart/alternative;
 boundary="------------080303020707000505020100"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------080303020707000505020100
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Here is the changes in the new version of the IPFIX protocol draft, 
posted today.

New sections:

- overview section written
- Vendor Specific Information Element
	New section 8.3.1 "IETF Exclusive Template FlowSet Format"
	New section 8.3.2 "Vendor Specified Template FlowSet Format"
	New section 9.1.1 "IETF Exclusive Options Template FlowSet Format"
	New section 9.1.2 "Vendor Specified Options Template FlowSet Format"
- Metering Process Statistics Option Template
 	New section 9.3 "Specific IPFIX Options Templates"
  	New section 9.3.1 "Metering Process Statistics Option Template"
  I've been trying to write down text that IMHO is the WG group consensus, as a starting point
**- time synchronization:
	UNIX Secs new definition
	sysUpTime removed from the header format
	New Section 10 "Export Packet UNIX Secs Computation and Flow Records Times"
	New Section 10.1 "microsecond precision"
	New Section 10.2 "nanosecond precision"
	New Section 10.3 "millisecond precision"
	New Section 10.4 "multiple precisions"
  I've been trying to write down text that IMHO is the WG group consensus, as a starting point
  Note that the example in section 17.1 has been updated with the new change
- A new section on the "Linkage with Information Model" defining the encoding rules and the 
"Reduced Size Encoding of Integral Types". Initial text proposed by Jeff Meyer
	New Section 11 "Linkage with the Information Model"
	New Section 11.1 "Boolean"
	New Section 11.2 "Byte"
	New Section 11.3 "UnsignedByte"
	New Section 11.4 "Short"
	...
	New Section 11.5 "Reduced Size Encoding of Integral Types"
  Again, this is a starting point for further discussion.
- A new section 15 Security Considerations.
  Initial proposed by Stewart Bryant. 
	New section 15.1 "IPsec Profile"
	New section 15.1.1 "Selectors"
	New section 15.1.2 "Mode"
	New section 15.1.3 "Key Management"
	New section 15.1.4 "Security Policy"
	New section 15.1.5 "Authentication"
	New section 15.1.6 "Availability"
	New section 15.2 "Network Architecture"
	New section 15.3 "When IPsec is not an Option"
	New section 15.4 "Transport Issues"
	New section 15.5 "Logging an IPFIX Attack"
  Again, this is a starting point for further discussion.
- quick "IANA considerations" section 16, which still needs some more work
- meterstats

Updates
- Length replaced the Count in the header. Example at the end of the draft is updated.
- Updated the Variable Length Data Type 
  As a consequence, the new term "Information Element" exists in the terminology section
- normative versus informative references

Editorial changes

- "Packet Layout" changed "IPFIX Message Layout"
- latest references: SCTP-PR, INFO_MODEL
- reference to [IPFIX-INFO] instead of "Field Type Definitions" section, which was a section in the NetFlow version 9 draft
- "Header" changed to "Message Header"
  Note that the example in section 17.1 has been updated with the new change
- changed the section 5.2.3.4 to stream
- removed any NetFlow or NetFlow collector references
- remove the UDP reference (anyway not used in the draft)
- Section 5.2.2 introduces 'SCTP streams,' I'd add "referred to hereafter
      as 'streams;' 'streams' is one of those words which means many different
      things in different contexts.
- Section 5.2.3.2, Source ID:
  change "MUST be kept unique for each such [Observation] domain" into "'MUST be kept unique for each such Observation domain"
- Section 5.2.5. What are "diverting" SID values?  Is it just a typo for "differing?" Corrected!
- Section 5.2.4, Collecting Process: typo in line 2, s/Collecting Process/Exporting Process/
Corrected.
- Section 5.2.4.  Wouldn't hurt to say SID (Source ID) to remin readers where SID was defined.
- add Ganesh Sadasivan and Stewart Bryant as authors as they prepared the text for Vendor Specific Information Element
- IPFIX Packet Header version changed from 0x0009 to 0x000a


As always, your feedback is welcome.
The first sections "open issues" and "action items" have been updated. 
Please correct me if I missed some.
Don't forget to also propose some new text when you address an issue ;)

To get the draft right, follow the procedure below

Regards, Benoit.

The file name is draft-ietf-ipfix-protocol-02.txt (IPFIX protocol draft 
version 2)

To get these files, please do the following...
   1. With a Netscape or Internet Explorer web browser open
      the following URL:
        http://www.cisco.com/pcgi-bin/specialaccess.cgi
   2. Enter all your details and at the 'Special Access Code' prompt,
      enter in MEANLSKM
   3. Click on the 'Submit' button.  This will bring you
      to a web page listing your files for pickup.
   4. Select each file listed.  Each selection will take
      you to the Software Download web page; click on any
      Site listed to download your file to your local disk.

 


--------------080303020707000505020100
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Dear all,<br>
<br>
Here is the changes in the new version of the IPFIX protocol draft,
posted today.<br>
<br>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<span style="text-decoration: underline;">New sections:</span><br>
<pre wrap="">- overview section written
- Vendor Specific Information Element
	New section 8.3.1 "IETF Exclusive Template FlowSet Format"
	New section 8.3.2 "Vendor Specified Template FlowSet Format"
	New section 9.1.1 "IETF Exclusive Options Template FlowSet Format"
	New section 9.1.2 "Vendor Specified Options Template FlowSet Format<span
 style="font-family: &quot;courier new&quot;,monospace;"><span
 style="font-weight: bold;">"
- </span>Metering Process Statistics Option Template
<span style="font-weight: bold;"> 	</span>New section 9.3 "Specific IPFIX Options Templates"
</span><span style="font-family: &quot;courier new&quot;,monospace;"><span
 style="font-weight: bold;">  	</span>New section 9.3.1 "Metering Process Statistics Option Template"
</span><span style="font-family: &quot;Courier New&quot;;">  I've been trying to write down text that IMHO is the WG group consensus, as a starting point</span>
<b style=""><span style="font-size: 12pt; font-family: &quot;Courier New&quot;;"></span></b>- time synchronization:
	UNIX Secs new definition
	sysUpTime removed from the header format
	New <span style="font-family: &quot;Courier New&quot;;">Section 10 "Export Packet UNIX Secs Computation and Flow Records Times"
</span>	New <span style="font-family: &quot;Courier New&quot;;">Section 10.1 "microsecond precision"
</span>	New <span style="font-family: &quot;Courier New&quot;;">Section 10.2 "nanosecond precision"
</span>	New <span style="font-family: &quot;Courier New&quot;;">Section 10.3 "millisecond precision"
</span>	New <span style="font-family: &quot;Courier New&quot;;">Section 10.4 "multiple precisions"</span><span
 style="font-family: &quot;Courier New&quot;;"></span><span
 style="font-family: &quot;Courier New&quot;;">
  I've been trying to write down text that IMHO is the WG group consensus, as a starting point
  Note that the example in section 17.1 has been updated with the new change
- A new section on the "</span>Linkage with Information Model" defining the encoding rules and the 
"Reduced Size Encoding of Integral Types". Initial text proposed by Jeff Meyer
	New <span style="font-family: &quot;Courier New&quot;;">Section 11 "</span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;">Linkage with the Information Model</span>"
	New Section 11.1 "Boolean"
	New Section 11.2 "Byte"
	New Section 11.3 "UnsignedByte"
	New Section 11.4 "Short"
	...
	New Section 11.5 "<span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;">Reduced Size Encoding of Integral Types"</span>
  Again, this is a starting point for further discussion.
- A new section 15 Security Considerations.
  Initial proposed by Stewart Bryant. 
	New section 15.1 "IPsec Profile"
	New section 15.1.1 "Selectors"
	New section 15.1.2 "Mode"
	New section 15.1.3 "Key Management"
	New section 15.1.4 "Security Policy"
	New section 15.1.5 "Authentication"
	New section 15.1.6 "Availability"
	New section 15.2 "Network Architecture"
	New section 15.3 "When IPsec is not an Option"
	New section 15.4 "Transport Issues"
	New section 15.5 "Logging an IPFIX Attack"
  Again, this is a starting point for further discussion.
<span style="font-family: &quot;courier new&quot;,monospace;"><span
 style="font-weight: bold;"></span></span>- quick "IANA considerations" section 16, which still needs some more work
- meterstats
</pre>
<pre wrap=""><span style="text-decoration: underline;">Updates</span><span
 style="font-family: &quot;Courier New&quot;;">
</span>- Length replaced the Count in the header. Example at the end of the draft is updated.
- Updated the Variable Length Data Type 
  As a consequence, the new term "Information Element" exists in the terminology section
- normative versus informative references</pre>
<span style="text-decoration: underline;">Editorial changes</span><br>
<pre wrap="">- "Packet Layout" changed "IPFIX Message Layout"
- latest references: SCTP-PR, INFO_MODEL
- reference to [IPFIX-INFO] instead of "Field Type Definitions" section, which was a section in the NetFlow version 9 draft
- "Header" changed to "Message Header"
<span style="font-family: &quot;Courier New&quot;;">  Note that the example in section 17.1 has been updated with the new change</span>
- changed the section 5.2.3.4 to stream
- removed any NetFlow or NetFlow collector references
- remove the UDP reference (anyway not used in the draft)
- Section 5.2.2 introduces 'SCTP streams,' I'd add "referred to hereafter
      as 'streams;' 'streams' is one of those words which means many different
      things in different contexts.
- Section 5.2.3.2, Source ID:
 &nbsp;change "MUST be kept unique for each such [Observation] domain" into "'MUST be kept unique for each such Observation domain"
- Section 5.2.5. What are "diverting" SID values?  Is it just a typo for "differing?" Corrected!
- Section 5.2.4, Collecting Process: typo in line 2,<span
 style="font-family: monospace;"> </span>s/Collecting Process/Exporting Process/
Corrected.
- Section 5.2.4.  Wouldn't hurt to say SID (Source ID) to remin readers where SID was defined.
- add Ganesh Sadasivan and Stewart Bryant as authors as they prepared the text for Vendor Specific Information Element
- IPFIX Packet Header version changed from 0x0009 to 0x000a
</pre>
<br>
As always, your feedback is welcome.<span
 style="font-family: monospace;"><br>
The first sections "</span>open issues" and "action items" have been
updated. Please correct me if I missed some.<br>
Don't forget to also propose some new text when you address an issue ;)<br>
<br>
To get the draft right, follow the procedure below<br>
<br>
Regards, Benoit.<br>
<br>
The file name is draft-ietf-ipfix-protocol-02.txt (IPFIX protocol draft
version 2)<br>
<br>
To get these files, please do the following...<br>
&nbsp;&nbsp; 1. With a Netscape or Internet Explorer web browser open<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the following URL:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="http://www.cisco.com/pcgi-bin/specialaccess.cgi">http://www.cisco.com/pcgi-bin/specialaccess.cgi</a><br>
&nbsp;&nbsp; 2. Enter all your details and at the 'Special Access Code' prompt, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enter in MEANLSKM<br>
&nbsp;&nbsp; 3. Click on the 'Submit' button.&nbsp; This will bring you<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to a web page listing your files for pickup.<br>
&nbsp;&nbsp; 4. Select each file listed.&nbsp; Each selection will take<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; you to the Software Download web page; click on any<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Site listed to download your file to your local disk.<br>
<br>
<blockquote type="cite"
 cite="mid1058264277.b1450232d4c64@hotlava.auckland.ac.nz"></blockquote>
<pre>&nbsp;</pre>
</body>
</html>

--------------080303020707000505020100--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 20 19:37:46 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03697
	for <ipfix-archive@lists.ietf.org>; Tue, 20 Jan 2004 19:37:46 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Aj6BH-0003yz-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 20 Jan 2004 18:25:15 -0600
Received: from central.switch.ch ([130.59.11.11])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Aj6BG-0003yt-00
	for ipfix@net.doit.wisc.edu; Tue, 20 Jan 2004 18:25:14 -0600
Received: from diotima.switch.ch ([130.59.4.87])
	by central.switch.ch with esmtp (Exim 3.20 #1)
	id 1Aj6BA-0003kj-00; Wed, 21 Jan 2004 01:25:08 +0100
Received: (from leinen@localhost)
	by diotima.switch.ch (8.11.7p1+Sun/8.11.7) id i0L0PKH25829;
	Wed, 21 Jan 2004 01:25:20 +0100 (MET)
X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon@limmat.switch.ch using -f
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Cc: "'Ipfix Wg' (E-mail) (E-mail)" <ipfix@net.doit.wisc.edu>
Subject: [ipfix] Re: AD Evaluation of: draft-leinen-ipfix-eval-contrib-01.txt
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
   7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
From: Simon Leinen <simon@limmat.switch.ch>
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC41F@nl0006exch001u.nl.lucent.com> (Bert
 Wijnen's message of "Mon, 22 Dec 2003 17:46:55 +0100")
References: <7D5D48D2CAA3D84C813F5B154F43B155028EC41F@nl0006exch001u.nl.lucent.com>
Date: Wed, 21 Jan 2004 01:25:20 +0100
Message-ID: <aa4quq5erz.fsf@diotima.switch.ch>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Bert,

thanks again for your review.  I have tried to address all your issues
in the revision draft-leinen-ipfix-eval-contrib-02 (see separate
announcement).

> Serious questions:
> - Many of the documents for the protcools that were evaluated 
>   are (possibly expired or soon to expire) internet-drafts.
>   Are you sure they are just informative and that there is no
>   need to read them in order to understand the evaluation?
>   Possibly they are not needed (I think I can see that after
>   reading the whol draft). It might be good to make an explicit
>   statement at the end of section 1 to say that you have extracted
>   the relevant information from the evaluation drafts and that
>   the detailed content of those drafts is not needed to understand 
>   this summary/executive/consolidated evaluation document.

I have added an appendix to explain the issue with the references.

> - Anyway, 
>   - I see that some have made it to RFC. 
>     RFC3423 - draft-kzhang-crane-protocol-05.txt
>     RFC3588 - draft-ietf-aaa-diameter-17.txt
>   - These are still there as (very old) drafts
>     draft-kzhang-ipfix-eval-crane-00.txt
>     draft-zander-ipfix-diameter-eval-00.txt
>     draft-calato-ipfix-lfap-eval-00.txt
>     draft-bclaise-netflow-9-00.txt
>   - I do not see/find:
>     expired: draft-riverstone-lfap-01.txt
>     expired: draft-riverstone-lfap-data-01.txt
>     expired: draft-claise-ipfix-eval-netflow-04.txt
>   And so on.

Those have been updated where possible, but the advocacy drafts
(...-eval-...) have been lost for good.

> - 6.  Security Considerations
>     The security mechanisms of the candidate protocols were discussed in
>     the section about the Security requirement (6.3.2).
>   I think it would be good to make a reference here to the doc that 
>   contains that sect 6.3.2 !! And porbably you mean sect 6.3.3. in
>   the ipfix requirements doc anyway!

The reference has been replaced with an document-internal one, and the
reference to the requirements doc fixed.  I have checked (hopefully)
all other section references to the requirements draft.

> Nits and admin comments

> - abstract speaks about "this draft", you man "this document"
>   draft dioes not read so well when it is an RFC.
> - first sentence in sect 4.1 missing right parenthesis
> - sect 4.10.3.2 3rd line: s/evel/level/

Thanks, those were easy to fix.

> - ANy idea, where reference [NDM-U-3.1] can be obtained/accessed?

I added an URL to the reference (sigh, why is this is difficult with
the XML tools?).

Regards,
-- 
Simon.

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 20 19:42:37 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03854
	for <ipfix-archive@lists.ietf.org>; Tue, 20 Jan 2004 19:42:37 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Aj6IA-00043l-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 20 Jan 2004 18:32:22 -0600
Received: from central.switch.ch ([130.59.11.11])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Aj6I9-00043g-00
	for ipfix@net.doit.wisc.edu; Tue, 20 Jan 2004 18:32:21 -0600
Received: from diotima.switch.ch ([130.59.4.87])
	by central.switch.ch with esmtp (Exim 3.20 #1)
	id 1Aj6I4-0005G2-00; Wed, 21 Jan 2004 01:32:16 +0100
Received: (from leinen@localhost)
	by diotima.switch.ch (8.11.7p1+Sun/8.11.7) id i0L0WSq25850;
	Wed, 21 Jan 2004 01:32:28 +0100 (MET)
X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon@limmat.switch.ch using -f
To: ipfix@net.doit.wisc.edu
CC: Bert Wijnen <bwijnen@lucent.com>
Subject: [ipfix] draft-leinen-ipfix-eval-contrib-02.txt posted
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
   7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
From: Simon Leinen <simon@limmat.switch.ch>
Date: Wed, 21 Jan 2004 01:32:28 +0100
Message-ID: <aaznci3zvn.fsf@diotima.switch.ch>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

I have submitted a revision of the protocol evaluation draft, to
address some issues that have been discovered in AD review - see my
response to Bert's mail.

For limited time, you can also access this over the Web as text:
  http://www.switch.ch/misc/leinen/ipfix/draft-leinen-ipfix-eval-contrib-02.txt
or HTML:
  http://www.switch.ch/misc/leinen/ipfix/draft-leinen-ipfix-eval-contrib-02.html

Diffs from -01:
  http://www.switch.ch/misc/leinen/ipfix/draft-leinen-ipfix-eval-contrib-01-02-diff.html

Regards,
-- 
Simon.

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 21 11:25:36 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28397
	for <ipfix-archive@lists.ietf.org>; Wed, 21 Jan 2004 11:25:36 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AjKeK-0006i9-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 21 Jan 2004 09:52:12 -0600
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AjKeJ-0006fb-00
	for ipfix@net.doit.wisc.edu; Wed, 21 Jan 2004 09:52:11 -0600
Received: from fokus.fraunhofer.de (dhcp119 [195.37.78.119])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i0LFq3L06414;
	Wed, 21 Jan 2004 16:52:03 +0100 (MET)
Message-ID: <400E9F8D.1090407@fokus.fraunhofer.de>
Date: Wed, 21 Jan 2004 16:49:33 +0100
From: Sebastian Zander <zander@fokus.fraunhofer.de>
Organization: Fraunhofer FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: stbryant@cisco.com
CC: "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [Fwd: Re: IPFIX protcol draft security section]
References: <400C0277.3040605@cisco.com> <400C14DC.9000902@fokus.fraunhofer.de> <400C61A1.8070703@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Stewart Bryant wrote:
 >
 >
 > Sebastian Zander wrote:
 >
 >> Some comments. First some general and the rest interspersed.
 >>
 >> - "Observer" should be changed to exporter (or exporting process)
 >> - We could/should add the use of TLS
 >
 >
 > TLS?

Transport Layer Security (rfc 2246). But I would have to read it
myself to find out how/if ipfix can be used with it.

 >>
 >> Stewart Bryant wrote:
 >>
 >>>
 >>> I did some work on the security section written
 >>> by Mark Fulmer for the IPFIX protocol draft.
 >>>
 >>> We can take the bit about transport pathology out
 >>> if it is too controversial, but it occured to me, as
 >>> I was thinking this out, that congestion is not
 >>> the only consideration when it comes to IPFIX
 >>> transport.
 >>>
 >>> - Stewart
 >>>
 >>>
 >>> Security Section
 >>> ----------------
 >>>
 >>> Because IPFIX can be used to collect billing information and
 >>> network forensics, confusing or blinding IPFIX must be seen
 >>> as a prime objective during a sophisticated network attack.
 >>>
 >>> If an attacker is in a position to inject false messages into
 >>> an IPFIX message stream this will allow them to send forged
 >>> flow records, options, or templates.  Forged templates may
 >>> impair the collectors ability to process any further flow records.
 >>> Forged flow records would have a direct effect on the application
 >>> using the flows, for example a billing system may generate
 >>> incorrect billing information.  Forged options may be able to
 >>> alter the meaning of flow records, for example if the sample
 >>> rate is changed.
 >>>
 >>> The IPFIX messages themselves may contain information of value
 >>> to an attacker, and thus care must be taken to confine their
 >>> visibility to authorized users.
 >>>
 >>> The IPFIX protocol runs over any IETF specified transport protocol
 >>
 >>
 >>
 >> The IPFIX protocol runs over IP and ...
 >>
 >
 > I was assuming that all IETF specified transports ran over IP.
 > The only thing that is likely to change this is TCP/MPLS, but
 > that is not on any WG agendas that I am aware of :)

Than I would put the transport protocols in parenthesis. Who knows
what other kinds of transport will be invented in the future... ;-)

 >
 >>> and hence the messages sent to the collector by the observer
 >>> may be secured using IPsec. However this does not address all of
 >>> the security issues in an IPsec deployment.
 >>>
 >>> IPsec Profile
 >>> -------------
 >>>
 >>> To secure messages between the observer and the collector
 >>> an IPFIX implementation MAY use IPsec. To ensure inter-working
 >>> between observers and collectors from different vendors,
 >>> the following IPsec profile MUST be supported. This profile
 >>> is derived from [USEIPSEC]
 >>>
 >
 > In useipsec the example is a BGP entity on a router, so what
 > we have here is a lightly edited version of the example.
 > I would that that IPFIX is quite a close cousin of Steve's
 > example.
 >
 >>> Selectors
 >>> ---------
 >>>
 >>> IPFIX runs between manually configured pairs of hosts on
 >>> the following transport ports (TBD).  The appropriate
 >>> selector would be the IPFIX collector for that port only.
 >>
 >>
 >>
 >> selector would be exporter collector pairs and port number
 >
 >
 > I think that the selection occurs at the server end of the
 > client server pair, so only one IP address is needed. Does
 > the exporter normally collect the collector of visa verse?
 > So it is only one IP address and one port.

AFAIK you need a selector on both ends.
I think in the general case you need pairs (see [USEIPSEC])
because each exporter collector pair can be a different SA
and there is a n to n relationship between exporters and
collectors (see arch draft). But it selector may be a wildcard.

 >
 >>
 >>> Note that if the observer is a router, the "loopback address"
 >>> is almost certainly the address to use.
 >>
 >>
 >>
 >> what does that mean?
 >>
 >
 > One of the non-interface addresses (because if you use an interafce
 > address and the interface goes down, so does the session)
 >
 >>> Mode
 >>> ----
 >>>
 >>> IPsec MUST be run in transport mode, and MAY use either the
 >>> Authentication Header (AH) [RFC2402] or the Security Protocol
 >>> (ESP) [RFC2406] depending on the perceived level of threat
 >>> to the IPSEC message content. The information being communicated
 >>> may be confidential, in which case ESP MUST used. If ESP is
 >>> used, the sender's IP address MUST be checked against the
 >>> IP address asserted in the key management exchange.
 >>>
 >>> The AH MUST be supported by an IPFIX implementation of IPsec.
 >>
 >>
 >>
 >> MAY either use AH or AH+ESP. AH MUST be used if authentication
 >> is required. ESP must be used if confidentiality is required.
 >> If somebody requires confidentiality and don't needs IP header
 >> auth then only ESP could be used but I think this not the usual
 >> case.
 >>
 >
 > Again I copied the BGP example, and I would have thought that this
 > was exactly correct. It's a bit late here, but I will double check
 > in the morning agains Steve's text.
 >
 >>
 >>> Key Management
 >>> --------------
 >>>
 >>> In most network, manual key management will be sufficient,
 >>> and reduces the complexity of the observer, albeit at a
 >>> cost of greater configuration complexity. Manual key management
 >>> MUST be supported. If a replay attack is considered likely,
 >>> an automated key management the IKE key managent system SHOULD
 >>> be used.
 >>>
 >>> Security Policy
 >>> ---------------
 >>> Connections should be accepted only from the designated peer.
 >>>
 >>> Authentication
 >>> --------------
 >>> Given the number of IPFIX capable routers likely to be
 >>> deployed by a large ISPs, it is likely that shared key
 >>> mechanisms are inadequate.  Consequently, where an automated
 >>> key management system is used, certificate-based IKE SHOULD
 >>> be supported.  Whatever scheme is used, it must tie back to a
 >>> source IP address in some fashion.
 >>>
 >>> Availability
 >>> ------------
 >>> It is accepted that IPsec will not be universally available
 >>> in IPFIX observers, and that where it is available, there may
 >>> be issues of throughput, which may itself raise security
 >>> issues. In such circumstances the other security measures
 >>> described in this draft provide some threat mitigation.
 >>>
 >>> Network Architecture
 >>> --------------------
 >>>
 >>> Ideally messages from the IPFIX observer to the IPFIX collector
 >>> should travel over a dedicated network such as a dedicated
 >>> point to point link. In all cases, useful protection is gained
 >>> by allocating observer and collector IP addresses from ranges
 >>> that are excluded from use for user traffic. By sending the
 >>
 >>
 >>
 >> why is that?
 >
 >
 > So that there is no routing path from a user to the IPFIX pair.
 >
 >>
 >>> IPFIX messages over a dedicated network, message IPFIX message
 >>> loss induced by user traffic congestion is minimized. However
 >>
 >>
 >>
 >> minimized to 0 I guess.
 >
 >
 > No, you could get congestion during an attack on th IPFIX
 > network depending on the type of attack, it's indensity,
 > and the capacity of the ipfix network. Now you would expect
 > it to be zero, but I don't think that you can guarantee it
 > and therefore should not say so in a security section.

Now I am confused. Didn't you say that user traffic does not
enter the separate network?

 >>
 >>> an attacker may trigger the generation of excessive IPFIX
 >>> messages, and to avoid information loss during such an attack
 >>> the IPFIX network must be adequately sized.
 >>>
 >>> The use of a dedicated network also prevents the IPFIX
 >>> messages from being inspected by an attacker.
 >>
 >>
 >>
 >> Presuming complete physical security which may be easy or not
 >> so easy to achieve
 >
 >
 > But if you could it would. A pt-pt direct link is one example.
 >
 >>
 >>> When IPsec is not an option
 >>> ---------------------------
 >>> When IPsec is not an option, perhaps due to performance issues,
 >>> but some level of protection against an insertion attack is
 >>> required, it is recommended that a 64 bit cookie [L2TPv3] be
 >>> included as a mandatory element within all messages.
 >>>
 >>> [Note if we follow this approach, we will need to do some work
 >>> on the protocol itself - SB]
 >>>
 >>> Without IPsec the IPFIX collector has no means to authenticate
 >>> an exporter other than the exporters Source IP address. Where
 >>
 >>
 >>
 >> which can be spoofed
 >
 >
 > exactly.
 >
 >>
 >>> large numbers of observers, proxies and collectors are used
 >>> in a network, it may be tempting for the administrator to
 >>> not impose source IP address restrictions, this leaves the
 >>> collector open to reception of invalid flows. The use
 >>> praxes using an open collector is therefore to be deprecated.
 >>>
 >>> Transport Issues
 >>> ----------------
 >>>
 >>> Some IPFIX security issues are dependent on the transport.
 >>> For example with UDP unsolicited messages may be received
 >>> and not detected, with a modern implementation of TCP with
 >>> good ISN randomization [XXX-REFERENCE] or SCTP these types
 >>> of attacks are much more difficult without an attacker
 >>> with access to snoop the packet flow.
 >>> [XXX-SCTP-BLIND-SPOOFING-REFERENCE]
 >>
 >>
 >>
 >> Wouldn't the IPFIX seq number be sufficient in case of UDP?
 >> Maybe it would need proper randomization...
 >>
 >
 > It's only 32 bits, see Mark Townsley's L2TP discussion on the
 > issues of such small sequence spaces. Which remind's me I think
 > we need some discussion on the sequence number recovery protocol
 > and its risks.

yes

 >>> An attacker may take advantage of the pathology of the
 >>> transport protocol or its common implementations to
 >>> mount and attack on IPFIX. This might be either as
 >>> an assault on IPFIX in its own right or intended to
 >>> blind IPFIX to prevent the recording of network forensics
 >>> as part of another attack.
 >>>
 >>> Under conditions where the attacker saturated IPFIX, for
 >>> example by  initiating the generating enormous numbers
 >>> of short lived flows, the behavior of the IPFIX transport
 >>> would determine the amount of evidence that was recorded.
 >>>
 >>> If the transport were UDP, then under network overload
 >>> conditions IPFIX would reduce to a form or sampled Netflow.
 >>> This means that the attacked could never be quite sure
 >>> that IPFIX was blinded, and that they may hence be leaving
 >>> forensics.
 >>>
 >>> If the transport were TCP, then the flow to the collector
 >>> would back off due to congestion discard and eventually stall
 >>> blinding the IPFIX system. An attack could then proceed
 >>> without further observation. The extent and duration of the
 >>> blindness would depend on the detail of the TCP implementation.
 >>>
 >>> SCTP-PR will have a different pathology under such a
 >>> saturation attack. Stale data at the head of the queue will
 >>> get flushed giving some visibility of the attack.
 >>>
 >>> Whilst the use of a congestion aware transport protocol is
 >>> highly desirable to protect the network from overload by
 >>> excessive IPFIX traffic, this is exactly wrong behavior
 >>> when IPFIX is being to diagnose a DoS attack, or an attack
 >>> proceeding under cover of a DoS attack. Under these circumstance
 >>> you want the IPFIX transport needs to be congestion neutral
 >>> (as is UDP), or congestion aggressive.
 >>
 >>
 >>
 >> But on the other hand if UDP is used an attacker might be able to
 >> saturate the separate network and therefore potentially blinding
 >> more than one observation point.
 >>
 >
 > I still think that it's worse with a congestion aware transport.
 > If you saturate that network, they all start to back off.

But if you have a separate network for ipfix traffic in case of udp
a user might be able to saturate this network by creating a large
number of small flows in probe(s) under attack. In case of tcp the
ipfix traffic from the probes under attack would have to back-off
which leaves some bandwidth for other probes.


 >>> Logging an IPFIX Attack
 >>> -----------------------
 >>>
 >>> IPFIX has a sequence number which increases with each message.  A
 >>> collector may detect out of sequence, dropped, or duplicate messages
 >>> by tracking the sequence number.  A collector SHOULD provide a logging
 >>> mechanism for tracking out of sequence messages.  Such out of sequence
 >>> messages may be due to congestion on the network link between the
 >>> exporter and collector, collector resource exhaustion where it can not
 >>> process the messages at their arrival rate, exporter resource exhaustion
 >>> where it can not transmit messages at their creation rate, out of order
 >>> packet reception, duplicate packet reception, an exporting process
 >>> reset,
 >>> or an attacker injecting false messages.
 >>>
 >>> Refs to be cleaned up
 >>> ---------------------
 >>>
 >>> [USEIPSEC] draft-bellovin-useipsec-02.txt
 >>> [L2TPv3] draft-ietf-l2tpext-l2tp-base-11.txt
 >>>
 >>>
 >>>
 >>>
 >>>
 >>>
 >>>
 >>>
 >>> --
 >>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
 >>> message body
 >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
 >>> "unsubscribe ipfix" in message body
 >>> Archive     http://ipfix.doit.wisc.edu/archive/
 >>>
 >>
 >>
 >
 >
 >


-- 
Sebastian Zander                         E-mail: zander@fokus.fraunhofer.de
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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 21 11:33:01 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28642
	for <ipfix-archive@lists.ietf.org>; Wed, 21 Jan 2004 11:33:01 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AjKv9-0007EZ-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 21 Jan 2004 10:09:35 -0600
Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AjKv8-0007ER-00
	for ipfix@net.doit.wisc.edu; Wed, 21 Jan 2004 10:09:34 -0600
Received: from fokus.fraunhofer.de (dhcp119 [195.37.78.119])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i0LG91L09973;
	Wed, 21 Jan 2004 17:09:01 +0100 (MET)
Message-ID: <400EA386.10804@fokus.fraunhofer.de>
Date: Wed, 21 Jan 2004 17:06:30 +0100
From: Sebastian Zander <zander@fokus.fraunhofer.de>
Organization: Fraunhofer FOKUS
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: stbryant@cisco.com
CC: Mark Fullmer <maf@splintered.net>,
        "'ipfix@net.doit.wisc.edu'"
 <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] [Fwd: Re: IPFIX protcol draft security section]
References: <400C0277.3040605@cisco.com> <400C14DC.9000902@fokus.fraunhofer.de> <400C61A1.8070703@cisco.com> <CDD51F5D-4B73-11D8-BAB4-000A95DA1C38@splintered.net> <400D7428.1010107@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Stewart Bryant wrote:
 >
 >
 > Mark Fullmer wrote:
 >
 >>
 >> On Jan 19, 2004, at 6:00 PM, Stewart Bryant wrote:
 >>
 >>>
 >>>
 >>> Sebastian Zander wrote:
 >>>
 >>>>> Some IPFIX security issues are dependent on the transport.
 >>>>> For example with UDP unsolicited messages may be received
 >>>>> and not detected, with a modern implementation of TCP with
 >>>>> good ISN randomization [XXX-REFERENCE] or SCTP these types
 >>>>> of attacks are much more difficult without an attacker
 >>>>> with access to snoop the packet flow.
 >>>>> [XXX-SCTP-BLIND-SPOOFING-REFERENCE]
 >>>>
 >>>>
 >>>> Wouldn't the IPFIX seq number be sufficient in case of UDP?
 >>>> Maybe it would need proper randomization...
 >>>
 >>>
 >>>
 >>> It's only 32 bits, see Mark Townsley's L2TP discussion on the
 >>> issues of such small sequence spaces. Which remind's me I think
 >>> we need some discussion on the sequence number recovery protocol
 >>> and its risks.
 >>>

TCP sequence number is also 32 bits. So I don't see the difference
between UDP and TCP (assuming a proper ipfix seq number).

 >>
 >> The problem is more fundamental than this.  How does a collector
 >> know what would be the ISN?  How does a collector know the difference
 >> between a new linecard being inserted, thus a new observation domain ID
 >> (also called Source ID in the draft) with a new sequence number space and
 >> an attacker picking a random Source ID and spoofing in forged flow data.
 >>
 >> A pre-configured cookie shared by the collector and exporter addresses
 >> these issues unless the attacker knows the cookie.

I don't think the big problem is to know the ISN because that's exactly the
same problem of knowing the cookie ;-). The problem is the small space (32bit)
and how the sequence number handling is done (what is the allowed window etc.).

 >
 >
 > We are actually in violent agreement here, a pre-configured
 > cookie is what we are both advocating (it is how it works in
 > one of the L2TPv3 modes),  however it is still vulnerable to sniffing.

I agree that the cookie is better than the sequence number. But from a security
viewpoint it is a potentially dangerous solution IMO. Not only because of sniffing
which makes the cookie completly useless. Also because if the cookie is pre-configured
it is static and will probably never change. This gives attackers a long time for
trying to discover it. Furthermore I would expect that people use the same cookie for
all their exporters and collectors because they don't want to manually set up
and maintain lots of cookies. So you have different points which can be attacked and
if the attackers suceeds at one point the secret cookie for all is exposed. Even worse
it could happen that there will be a default cookie setup in a software or hardware
product which the admin "forgets" to change. Actually in the old days systems where
delivered with a default root password... At least these threads must be discussed
in the draft together with recommendations to mitigate them.

I thought about a different proposal: have a secret. Than a crypto hash over the exporter id,
collector id, time and secret can be put into the packet. This way you have something
like a session key which can be changed from time to time and the master key (the
secret) never gets exposed. The collector has to compute the session key only
when it changes, otherwise it just compares the actual value with the last one.
This way you have 1) a number of different keys and if one is discovered only one
exporter-collector connection is affected, 2) a new key can be produced without changing
the master secret for all. If the exporter id is not publicly known even the knowledge of
the secret would not enable an attacker to produce a proper session key (assuming the
exporter id is not easily guessable). Still vulnerable to sniffing.

Actually I am not really convinced of having something like a cookie at all because
either you run ipfix in your "secure" network: no sniffing and spoofing can be prevented
by proper ingress filtering (what you pointed out before). Otherwise use IPSec or TLS.

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: zander@fokus.fraunhofer.de
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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 21 12:29:04 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01105
	for <ipfix-archive@lists.ietf.org>; Wed, 21 Jan 2004 12:28:59 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AjM0u-0001Hf-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 21 Jan 2004 11:19:36 -0600
Received: from bay3-f4.bay3.hotmail.com ([65.54.169.4] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AjM0t-0001HZ-00
	for ipfix@net.doit.wisc.edu; Wed, 21 Jan 2004 11:19:35 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 21 Jan 2004 09:19:32 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Wed, 21 Jan 2004 17:19:31 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: zander@fokus.fraunhofer.de, stbryant@cisco.com
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [Fwd: Re: IPFIX protcol draft security section]
Date: Wed, 21 Jan 2004 09:19:31 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F4A8v8HwuGI7WR00075e2a@hotmail.com>
X-OriginalArrivalTime: 21 Jan 2004 17:19:32.0075 (UTC) FILETIME=[BBDC5BB0:01C3E042]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Sebastian,

  In the case of TLS, it would seem that both SCTP and TCP could make use of 
this.  Utillizing both client and server certificates would provide strong 
mutual authentication of both parties (exporter and collector) and allow for 
complete data privacty.

  For UDP, IPSec, or appropriate configuration of private LANs would seem to 
be the way to go.

  In either case, mechanisms for distributing public keys (TLS) or shared 
secrets (IPSec) may be cumbersome, but this is not a problem unique to 
IPFIX.  I'm not sure IPFIX needs to explicitly address how keys/secrets are 
configured into the systems.

-- Jeff

>From: Sebastian Zander <zander@fokus.fraunhofer.de>
>To: stbryant@cisco.com
>CC: "'ipfix@net.doit.wisc.edu'" <ipfix@net.doit.wisc.edu>
>Subject: Re: [ipfix] [Fwd: Re: IPFIX protcol draft security section]
>Date: Wed, 21 Jan 2004 16:49:33 +0100
>
>Stewart Bryant wrote:
> >
> >
> > Sebastian Zander wrote:
> >
> >> Some comments. First some general and the rest interspersed.
> >>
> >> - "Observer" should be changed to exporter (or exporting process)
> >> - We could/should add the use of TLS
> >
> >
> > TLS?
>
>Transport Layer Security (rfc 2246). But I would have to read it
>myself to find out how/if ipfix can be used with it.
>
> >>
> >> Stewart Bryant wrote:
> >>
> >>>
> >>> I did some work on the security section written
> >>> by Mark Fulmer for the IPFIX protocol draft.
> >>>
> >>> We can take the bit about transport pathology out
> >>> if it is too controversial, but it occured to me, as
> >>> I was thinking this out, that congestion is not
> >>> the only consideration when it comes to IPFIX
> >>> transport.
> >>>
> >>> - Stewart
> >>>
> >>>
> >>> Security Section
> >>> ----------------
> >>>
> >>> Because IPFIX can be used to collect billing information and
> >>> network forensics, confusing or blinding IPFIX must be seen
> >>> as a prime objective during a sophisticated network attack.
> >>>
> >>> If an attacker is in a position to inject false messages into
> >>> an IPFIX message stream this will allow them to send forged
> >>> flow records, options, or templates.  Forged templates may
> >>> impair the collectors ability to process any further flow records.
> >>> Forged flow records would have a direct effect on the application
> >>> using the flows, for example a billing system may generate
> >>> incorrect billing information.  Forged options may be able to
> >>> alter the meaning of flow records, for example if the sample
> >>> rate is changed.
> >>>
> >>> The IPFIX messages themselves may contain information of value
> >>> to an attacker, and thus care must be taken to confine their
> >>> visibility to authorized users.
> >>>
> >>> The IPFIX protocol runs over any IETF specified transport protocol
> >>
> >>
> >>
> >> The IPFIX protocol runs over IP and ...
> >>
> >
> > I was assuming that all IETF specified transports ran over IP.
> > The only thing that is likely to change this is TCP/MPLS, but
> > that is not on any WG agendas that I am aware of :)
>
>Than I would put the transport protocols in parenthesis. Who knows
>what other kinds of transport will be invented in the future... ;-)
>
> >
> >>> and hence the messages sent to the collector by the observer
> >>> may be secured using IPsec. However this does not address all of
> >>> the security issues in an IPsec deployment.
> >>>
> >>> IPsec Profile
> >>> -------------
> >>>
> >>> To secure messages between the observer and the collector
> >>> an IPFIX implementation MAY use IPsec. To ensure inter-working
> >>> between observers and collectors from different vendors,
> >>> the following IPsec profile MUST be supported. This profile
> >>> is derived from [USEIPSEC]
> >>>
> >
> > In useipsec the example is a BGP entity on a router, so what
> > we have here is a lightly edited version of the example.
> > I would that that IPFIX is quite a close cousin of Steve's
> > example.
> >
> >>> Selectors
> >>> ---------
> >>>
> >>> IPFIX runs between manually configured pairs of hosts on
> >>> the following transport ports (TBD).  The appropriate
> >>> selector would be the IPFIX collector for that port only.
> >>
> >>
> >>
> >> selector would be exporter collector pairs and port number
> >
> >
> > I think that the selection occurs at the server end of the
> > client server pair, so only one IP address is needed. Does
> > the exporter normally collect the collector of visa verse?
> > So it is only one IP address and one port.
>
>AFAIK you need a selector on both ends.
>I think in the general case you need pairs (see [USEIPSEC])
>because each exporter collector pair can be a different SA
>and there is a n to n relationship between exporters and
>collectors (see arch draft). But it selector may be a wildcard.
>
> >
> >>
> >>> Note that if the observer is a router, the "loopback address"
> >>> is almost certainly the address to use.
> >>
> >>
> >>
> >> what does that mean?
> >>
> >
> > One of the non-interface addresses (because if you use an interafce
> > address and the interface goes down, so does the session)
> >
> >>> Mode
> >>> ----
> >>>
> >>> IPsec MUST be run in transport mode, and MAY use either the
> >>> Authentication Header (AH) [RFC2402] or the Security Protocol
> >>> (ESP) [RFC2406] depending on the perceived level of threat
> >>> to the IPSEC message content. The information being communicated
> >>> may be confidential, in which case ESP MUST used. If ESP is
> >>> used, the sender's IP address MUST be checked against the
> >>> IP address asserted in the key management exchange.
> >>>
> >>> The AH MUST be supported by an IPFIX implementation of IPsec.
> >>
> >>
> >>
> >> MAY either use AH or AH+ESP. AH MUST be used if authentication
> >> is required. ESP must be used if confidentiality is required.
> >> If somebody requires confidentiality and don't needs IP header
> >> auth then only ESP could be used but I think this not the usual
> >> case.
> >>
> >
> > Again I copied the BGP example, and I would have thought that this
> > was exactly correct. It's a bit late here, but I will double check
> > in the morning agains Steve's text.
> >
> >>
> >>> Key Management
> >>> --------------
> >>>
> >>> In most network, manual key management will be sufficient,
> >>> and reduces the complexity of the observer, albeit at a
> >>> cost of greater configuration complexity. Manual key management
> >>> MUST be supported. If a replay attack is considered likely,
> >>> an automated key management the IKE key managent system SHOULD
> >>> be used.
> >>>
> >>> Security Policy
> >>> ---------------
> >>> Connections should be accepted only from the designated peer.
> >>>
> >>> Authentication
> >>> --------------
> >>> Given the number of IPFIX capable routers likely to be
> >>> deployed by a large ISPs, it is likely that shared key
> >>> mechanisms are inadequate.  Consequently, where an automated
> >>> key management system is used, certificate-based IKE SHOULD
> >>> be supported.  Whatever scheme is used, it must tie back to a
> >>> source IP address in some fashion.
> >>>
> >>> Availability
> >>> ------------
> >>> It is accepted that IPsec will not be universally available
> >>> in IPFIX observers, and that where it is available, there may
> >>> be issues of throughput, which may itself raise security
> >>> issues. In such circumstances the other security measures
> >>> described in this draft provide some threat mitigation.
> >>>
> >>> Network Architecture
> >>> --------------------
> >>>
> >>> Ideally messages from the IPFIX observer to the IPFIX collector
> >>> should travel over a dedicated network such as a dedicated
> >>> point to point link. In all cases, useful protection is gained
> >>> by allocating observer and collector IP addresses from ranges
> >>> that are excluded from use for user traffic. By sending the
> >>
> >>
> >>
> >> why is that?
> >
> >
> > So that there is no routing path from a user to the IPFIX pair.
> >
> >>
> >>> IPFIX messages over a dedicated network, message IPFIX message
> >>> loss induced by user traffic congestion is minimized. However
> >>
> >>
> >>
> >> minimized to 0 I guess.
> >
> >
> > No, you could get congestion during an attack on th IPFIX
> > network depending on the type of attack, it's indensity,
> > and the capacity of the ipfix network. Now you would expect
> > it to be zero, but I don't think that you can guarantee it
> > and therefore should not say so in a security section.
>
>Now I am confused. Didn't you say that user traffic does not
>enter the separate network?
>
> >>
> >>> an attacker may trigger the generation of excessive IPFIX
> >>> messages, and to avoid information loss during such an attack
> >>> the IPFIX network must be adequately sized.
> >>>
> >>> The use of a dedicated network also prevents the IPFIX
> >>> messages from being inspected by an attacker.
> >>
> >>
> >>
> >> Presuming complete physical security which may be easy or not
> >> so easy to achieve
> >
> >
> > But if you could it would. A pt-pt direct link is one example.
> >
> >>
> >>> When IPsec is not an option
> >>> ---------------------------
> >>> When IPsec is not an option, perhaps due to performance issues,
> >>> but some level of protection against an insertion attack is
> >>> required, it is recommended that a 64 bit cookie [L2TPv3] be
> >>> included as a mandatory element within all messages.
> >>>
> >>> [Note if we follow this approach, we will need to do some work
> >>> on the protocol itself - SB]
> >>>
> >>> Without IPsec the IPFIX collector has no means to authenticate
> >>> an exporter other than the exporters Source IP address. Where
> >>
> >>
> >>
> >> which can be spoofed
> >
> >
> > exactly.
> >
> >>
> >>> large numbers of observers, proxies and collectors are used
> >>> in a network, it may be tempting for the administrator to
> >>> not impose source IP address restrictions, this leaves the
> >>> collector open to reception of invalid flows. The use
> >>> praxes using an open collector is therefore to be deprecated.
> >>>
> >>> Transport Issues
> >>> ----------------
> >>>
> >>> Some IPFIX security issues are dependent on the transport.
> >>> For example with UDP unsolicited messages may be received
> >>> and not detected, with a modern implementation of TCP with
> >>> good ISN randomization [XXX-REFERENCE] or SCTP these types
> >>> of attacks are much more difficult without an attacker
> >>> with access to snoop the packet flow.
> >>> [XXX-SCTP-BLIND-SPOOFING-REFERENCE]
> >>
> >>
> >>
> >> Wouldn't the IPFIX seq number be sufficient in case of UDP?
> >> Maybe it would need proper randomization...
> >>
> >
> > It's only 32 bits, see Mark Townsley's L2TP discussion on the
> > issues of such small sequence spaces. Which remind's me I think
> > we need some discussion on the sequence number recovery protocol
> > and its risks.
>
>yes
>
> >>> An attacker may take advantage of the pathology of the
> >>> transport protocol or its common implementations to
> >>> mount and attack on IPFIX. This might be either as
> >>> an assault on IPFIX in its own right or intended to
> >>> blind IPFIX to prevent the recording of network forensics
> >>> as part of another attack.
> >>>
> >>> Under conditions where the attacker saturated IPFIX, for
> >>> example by  initiating the generating enormous numbers
> >>> of short lived flows, the behavior of the IPFIX transport
> >>> would determine the amount of evidence that was recorded.
> >>>
> >>> If the transport were UDP, then under network overload
> >>> conditions IPFIX would reduce to a form or sampled Netflow.
> >>> This means that the attacked could never be quite sure
> >>> that IPFIX was blinded, and that they may hence be leaving
> >>> forensics.
> >>>
> >>> If the transport were TCP, then the flow to the collector
> >>> would back off due to congestion discard and eventually stall
> >>> blinding the IPFIX system. An attack could then proceed
> >>> without further observation. The extent and duration of the
> >>> blindness would depend on the detail of the TCP implementation.
> >>>
> >>> SCTP-PR will have a different pathology under such a
> >>> saturation attack. Stale data at the head of the queue will
> >>> get flushed giving some visibility of the attack.
> >>>
> >>> Whilst the use of a congestion aware transport protocol is
> >>> highly desirable to protect the network from overload by
> >>> excessive IPFIX traffic, this is exactly wrong behavior
> >>> when IPFIX is being to diagnose a DoS attack, or an attack
> >>> proceeding under cover of a DoS attack. Under these circumstance
> >>> you want the IPFIX transport needs to be congestion neutral
> >>> (as is UDP), or congestion aggressive.
> >>
> >>
> >>
> >> But on the other hand if UDP is used an attacker might be able to
> >> saturate the separate network and therefore potentially blinding
> >> more than one observation point.
> >>
> >
> > I still think that it's worse with a congestion aware transport.
> > If you saturate that network, they all start to back off.
>
>But if you have a separate network for ipfix traffic in case of udp
>a user might be able to saturate this network by creating a large
>number of small flows in probe(s) under attack. In case of tcp the
>ipfix traffic from the probes under attack would have to back-off
>which leaves some bandwidth for other probes.
>
>
> >>> Logging an IPFIX Attack
> >>> -----------------------
> >>>
> >>> IPFIX has a sequence number which increases with each message.  A
> >>> collector may detect out of sequence, dropped, or duplicate messages
> >>> by tracking the sequence number.  A collector SHOULD provide a logging
> >>> mechanism for tracking out of sequence messages.  Such out of sequence
> >>> messages may be due to congestion on the network link between the
> >>> exporter and collector, collector resource exhaustion where it can not
> >>> process the messages at their arrival rate, exporter resource 
>exhaustion
> >>> where it can not transmit messages at their creation rate, out of 
>order
> >>> packet reception, duplicate packet reception, an exporting process
> >>> reset,
> >>> or an attacker injecting false messages.
> >>>
> >>> Refs to be cleaned up
> >>> ---------------------
> >>>
> >>> [USEIPSEC] draft-bellovin-useipsec-02.txt
> >>> [L2TPv3] draft-ietf-l2tpext-l2tp-base-11.txt
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in
> >>> message body
> >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> >>> "unsubscribe ipfix" in message body
> >>> Archive     http://ipfix.doit.wisc.edu/archive/
> >>>
> >>
> >>
> >
> >
> >
>
>
>--
>Sebastian Zander                         E-mail: zander@fokus.fraunhofer.de
>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:majordomo@net.doit.wisc.edu and say "help" in message 
>body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/

_________________________________________________________________
Check out the coupons and bargains on MSN Offers! 
http://shopping.msn.com/softcontent/softcontent.aspx?scmId=1418


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 21 15:52:27 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08055
	for <ipfix-archive@lists.ietf.org>; Wed, 21 Jan 2004 15:52:26 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AjOpH-00063s-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 21 Jan 2004 14:19:47 -0600
Received: from [66.250.216.130] (helo=hosting.splintered.net)
	by mil.doit.wisc.edu with smtp (Exim 3.13 #1)
	id 1AjOpG-000611-00
	for ipfix@net.doit.wisc.edu; Wed, 21 Jan 2004 14:19:46 -0600
Received: (qmail 81217 invoked by alias); 21 Jan 2004 20:18:24 -0000
Received: from unknown (HELO ?IPv6:::1?) (66.250.216.130)
  by 66.250.216.130 with SMTP; 21 Jan 2004 20:18:24 -0000
Mime-Version: 1.0 (Apple Message framework v609)
Content-Transfer-Encoding: 7bit
Message-Id: <F761A180-4C4E-11D8-B34C-000A95DA1C38@eng.oar.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: "'ipfix@net.doit.wisc.edu' (E-mail)" <ipfix@net.doit.wisc.edu>
From: Mark Fullmer <maf@eng.oar.net>
Subject: [ipfix] [Fwd: Re: IPFIX protcol draft security section]
Date: Wed, 21 Jan 2004 15:18:24 -0500
X-Mailer: Apple Mail (2.609)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



On Jan 21, 2004, at 11:06 AM, Sebastian Zander wrote:
>
> I agree that the cookie is better than the sequence number. But from a 
> security
> viewpoint it is a potentially dangerous solution IMO. Not only because 
> of sniffing
> which makes the cookie completly useless. Also because if the cookie 
> is pre-configured

It's a light weight proposal that is only applicable to blind attacks, 
ie they
don't have access to the wire.

> it is static and will probably never change. This gives attackers a 
> long time for
> trying to discover it. Furthermore I would expect that people use the 
> same cookie for
> all their exporters and collectors because they don't want to manually 
> set up
> and maintain lots of cookies. So you have different points which can 
> be attacked and
> if the attackers suceeds at one point the secret cookie for all is 
> exposed. Even worse
> it could happen that there will be a default cookie setup in a 
> software or hardware
> product which the admin "forgets" to change. Actually in the old days 
> systems where
> delivered with a default root password... At least these threads must 
> be discussed
> in the draft together with recommendations to mitigate them.

A collector would need to be configured to require the cookie.  There 
wouldn't need
to be defaults.

>
> I thought about a different proposal: have a secret. Than a crypto 
> hash over the exporter id,
> collector id, time and secret can be put into the packet. This way you 
> have something
> like a session key which can be changed from time to time and the 
> master key (the
> secret) never gets exposed. The collector has to compute the session 
> key only
> when it changes, otherwise it just compares the actual value with the 
> last one.

I was thinking about something like this too, the problem is "time."  
Lose time
synchronization and you lose your flows.  Probably not a requirement 
that would fly.

> This way you have 1) a number of different keys and if one is 
> discovered only one
> exporter-collector connection is affected, 2) a new key can be 
> produced without changing
> the master secret for all. If the exporter id is not publicly known 
> even the knowledge of
> the secret would not enable an attacker to produce a proper session 
> key (assuming the
> exporter id is not easily guessable). Still vulnerable to sniffing.
>
> Actually I am not really convinced of having something like a cookie 
> at all because
> either you run ipfix in your "secure" network: no sniffing and 
> spoofing can be prevented
> by proper ingress filtering (what you pointed out before). Otherwise 
> use IPSec or TLS.

IPSEC, even just message authentication is probably too much to ask for 
current
service provider backbone routers.  Cookies provide a useful middle 
ground.

--
mark


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 27 02:47:44 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23386
	for <ipfix-archive@lists.ietf.org>; Tue, 27 Jan 2004 02:47:44 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AlNVG-0006Un-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 27 Jan 2004 01:19:18 -0600
Received: from bay3-f36.bay3.hotmail.com ([65.54.169.36] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AlNVF-0006Uh-00
	for ipfix@net.doit.wisc.edu; Tue, 27 Jan 2004 01:19:17 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 26 Jan 2004 23:19:16 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Tue, 27 Jan 2004 07:19:16 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] [issue] INFO-25  Options data is not addressed in info-model
Date: Mon, 26 Jan 2004 23:19:16 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F36P4GHHU9ObBj00011d27@hotmail.com>
X-OriginalArrivalTime: 27 Jan 2004 07:19:16.0496 (UTC) FILETIME=[DF61A100:01C3E4A5]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Currently the content of the information model deals with information 
elements related
to a single flow (or possibly aggregated set of flows).

There is another class of information which pertains to details about the 
exporter itself.
(e.g. total number of flows exported, drops and other items).  Some of these 
are
currently described in the protocol draft under the discussion of "Option 
Templates".

These information elements should be described in the information model as 
well. Probably
in a separate section dealing with "Exporter Detail Information".

-- Jeff Meyer

_________________________________________________________________
Get a FREE online virus check for your PC here, from McAfee. 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 27 02:53:15 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23620
	for <ipfix-archive@lists.ietf.org>; Tue, 27 Jan 2004 02:53:15 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AlNPy-0006Rh-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 27 Jan 2004 01:13:50 -0600
Received: from bay3-f10.bay3.hotmail.com ([65.54.169.10] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AlNPx-0006Rc-00
	for ipfix@net.doit.wisc.edu; Tue, 27 Jan 2004 01:13:49 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 26 Jan 2004 23:13:48 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Tue, 27 Jan 2004 07:13:48 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-20 Separate Normative from Informative References
Date: Mon, 26 Jan 2004 23:13:48 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F10rCZpmM4E4Rn00005547@hotmail.com>
X-OriginalArrivalTime: 27 Jan 2004 07:13:48.0935 (UTC) FILETIME=[1C23C970:01C3E4A5]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This will be corrected in the next ipfix-info-03 draft.

_________________________________________________________________
Rethink your business approach for the new year with the helpful tips here. 
http://special.msn.com/bcentral/prep04.armx


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 27 03:05:15 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23934
	for <ipfix-archive@lists.ietf.org>; Tue, 27 Jan 2004 03:05:15 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AlNZ5-0006mh-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 27 Jan 2004 01:23:15 -0600
Received: from bay3-f36.bay3.hotmail.com ([65.54.169.36] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AlNZ4-0006mc-00
	for ipfix@net.doit.wisc.edu; Tue, 27 Jan 2004 01:23:14 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 26 Jan 2004 23:23:13 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Tue, 27 Jan 2004 07:23:13 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] [issue]  INFO-26  Section 7 of info-02 should be reworded
Date: Mon, 26 Jan 2004 23:23:13 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F36NTXiQD9Eg4400011d3d@hotmail.com>
X-OriginalArrivalTime: 27 Jan 2004 07:23:13.0499 (UTC) FILETIME=[6CA56AB0:01C3E4A6]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

The current section 7 describes in general the benefits of an XML based 
information model,
some would say too much.  It does not describe any specific applications of 
this approach.

Specifically the ability to serialize as either XML or binary documents, 
collections of received
IPFIX flow records is a benefit.  This can be realized with existing open 
source tools from
IPDR.  Elaborating on how this connection can be established would be 
helpful to the
community, since persisting collected sets of flows is a common task in 
today's netflow
deployments.

-- Jeff Meyer

_________________________________________________________________
Find high-speed ‘net deals — comparison-shop your local providers here. 
https://broadband.msn.com


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 27 03:24:08 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24423
	for <ipfix-archive@lists.ietf.org>; Tue, 27 Jan 2004 03:24:08 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AlO0M-0007Pn-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 27 Jan 2004 01:51:26 -0600
Received: from bay3-f39.bay3.hotmail.com ([65.54.169.39] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AlO0L-0007Pg-00
	for ipfix@net.doit.wisc.edu; Tue, 27 Jan 2004 01:51:25 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 26 Jan 2004 23:51:24 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Tue, 27 Jan 2004 07:51:24 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] [issue] INFO-27  Information model reconciliation with NetflowV9 Draft
Date: Mon, 26 Jan 2004 23:51:24 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F39op69TeCDXRT00009a6f@hotmail.com>
X-OriginalArrivalTime: 27 Jan 2004 07:51:24.0932 (UTC) FILETIME=[5CD19C40:01C3E4AA]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

There are a large number of information elements defined in the NFv9 draft 
in
section 8 "Field Type Definitions" which are not currently part of the IPFIX 
information
model.

There are a smaller set of information elements currently defined in 
ipfix-info which
are not defined in NFv9.

Note all common IE's are defined to have the same fieldId value.

A summary of the deltas between the two documents is available at:

  http://inetpix.com/ipfix/NFv9_IPFIX_info_comparison.xls

It would appear that some of the information elements defined in NFv9 are 
actually
option data vs. flow data (see issue INFO-26 at 
http://ipfix.doit.wisc.edu/archive/2360.html).

Proposal would be to take a subset of these information elements from NFv9 
into ipfix.

The value of the current ipfix-info elements which fall outside of NFv9 is 
also worth
questioning.

-- Jeff Meyer

_________________________________________________________________
Let the new MSN Premium Internet Software make the most of your high-speed 
experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 27 03:25:33 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24499
	for <ipfix-archive@lists.ietf.org>; Tue, 27 Jan 2004 03:25:33 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AlNnM-0007HN-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 27 Jan 2004 01:38:00 -0600
Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AlNnL-0007HG-00
	for ipfix@net.doit.wisc.edu; Tue, 27 Jan 2004 01:37:59 -0600
Received: from cisco.com (dhcp-bru-peg2-vl28-144-254-0-49.cisco.com [144.254.0.49])
	by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i0R7bw704433;
	Tue, 27 Jan 2004 08:37:58 +0100 (CET)
Message-ID: <40161555.5070102@cisco.com>
Date: Tue, 27 Jan 2004 08:37:57 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ipfix <ipfix@net.doit.wisc.edu>
CC: Benoit Claise <bclaise@cisco.com>
Subject: Re: [ipfix] draft-ietf-ipfix-protocol-02.txt
References: <400D7901.4090000@cisco.com>
In-Reply-To: <400D7901.4090000@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------080902000007020503020205"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is a multi-part message in MIME format.
--------------080902000007020503020205
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

While rereading the protocol draft, I realized that I did a mistake 
(forgot to update something).
To be consistent with the time proposal, the packet header should look like:

1.1 Section 8.1 Header Format

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Version Number          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           UNIX Secs                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Sequence Number                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Source ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


This will be corrected for the next protocol draft version.

Regards, Benoit.

> Dear all,
>
> Here is the changes in the new version of the IPFIX protocol draft, 
> posted today.
>
> New sections:
>
>- overview section written
>- Vendor Specific Information Element
>	New section 8.3.1 "IETF Exclusive Template FlowSet Format"
>	New section 8.3.2 "Vendor Specified Template FlowSet Format"
>	New section 9.1.1 "IETF Exclusive Options Template FlowSet Format"
>	New section 9.1.2 "Vendor Specified Options Template FlowSet Format"
>- Metering Process Statistics Option Template
> 	New section 9.3 "Specific IPFIX Options Templates"
>  	New section 9.3.1 "Metering Process Statistics Option Template"
>  I've been trying to write down text that IMHO is the WG group consensus, as a starting point
>- time synchronization:
>	UNIX Secs new definition
>	sysUpTime removed from the header format
>	New Section 10 "Export Packet UNIX Secs Computation and Flow Records Times"
>	New Section 10.1 "microsecond precision"
>	New Section 10.2 "nanosecond precision"
>	New Section 10.3 "millisecond precision"
>	New Section 10.4 "multiple precisions"
>  I've been trying to write down text that IMHO is the WG group consensus, as a starting point
>  Note that the example in section 17.1 has been updated with the new change
>- A new section on the "Linkage with Information Model" defining the encoding rules and the 
>"Reduced Size Encoding of Integral Types". Initial text proposed by Jeff Meyer
>	New Section 11 "Linkage with the Information Model"
>	New Section 11.1 "Boolean"
>	New Section 11.2 "Byte"
>	New Section 11.3 "UnsignedByte"
>	New Section 11.4 "Short"
>	...
>	New Section 11.5 "Reduced Size Encoding of Integral Types"
>  Again, this is a starting point for further discussion.
>- A new section 15 Security Considerations.
>  Initial proposed by Stewart Bryant. 
>	New section 15.1 "IPsec Profile"
>	New section 15.1.1 "Selectors"
>	New section 15.1.2 "Mode"
>	New section 15.1.3 "Key Management"
>	New section 15.1.4 "Security Policy"
>	New section 15.1.5 "Authentication"
>	New section 15.1.6 "Availability"
>	New section 15.2 "Network Architecture"
>	New section 15.3 "When IPsec is not an Option"
>	New section 15.4 "Transport Issues"
>	New section 15.5 "Logging an IPFIX Attack"
>  Again, this is a starting point for further discussion.
>- quick "IANA considerations" section 16, which still needs some more work
>- meterstats
>  
>
>Updates
>- Length replaced the Count in the header. Example at the end of the draft is updated.
>- Updated the Variable Length Data Type 
>  As a consequence, the new term "Information Element" exists in the terminology section
>- normative versus informative references
>
> Editorial changes
>
>- "Packet Layout" changed "IPFIX Message Layout"
>- latest references: SCTP-PR, INFO_MODEL
>- reference to [IPFIX-INFO] instead of "Field Type Definitions" section, which was a section in the NetFlow version 9 draft
>- "Header" changed to "Message Header"
>  Note that the example in section 17.1 has been updated with the new change
>- changed the section 5.2.3.4 to stream
>- removed any NetFlow or NetFlow collector references
>- remove the UDP reference (anyway not used in the draft)
>- Section 5.2.2 introduces 'SCTP streams,' I'd add "referred to hereafter
>      as 'streams;' 'streams' is one of those words which means many different
>      things in different contexts.
>- Section 5.2.3.2, Source ID:
>  change "MUST be kept unique for each such [Observation] domain" into "'MUST be kept unique for each such Observation domain"
>- Section 5.2.5. What are "diverting" SID values?  Is it just a typo for "differing?" Corrected!
>- Section 5.2.4, Collecting Process: typo in line 2, s/Collecting Process/Exporting Process/
>Corrected.
>- Section 5.2.4.  Wouldn't hurt to say SID (Source ID) to remin readers where SID was defined.
>- add Ganesh Sadasivan and Stewart Bryant as authors as they prepared the text for Vendor Specific Information Element
>- IPFIX Packet Header version changed from 0x0009 to 0x000a
>  
>
>
> As always, your feedback is welcome.
> The first sections "open issues" and "action items" have been updated. 
> Please correct me if I missed some.
> Don't forget to also propose some new text when you address an issue ;)
>
> To get the draft right, follow the procedure below
>
> Regards, Benoit.
>
> The file name is draft-ietf-ipfix-protocol-02.txt (IPFIX protocol 
> draft version 2)
>
> To get these files, please do the following...
>    1. With a Netscape or Internet Explorer web browser open
>       the following URL:
>         http://www.cisco.com/pcgi-bin/specialaccess.cgi
>    2. Enter all your details and at the 'Special Access Code' prompt,
>       enter in MEANLSKM
>    3. Click on the 'Submit' button.  This will bring you
>       to a web page listing your files for pickup.
>    4. Select each file listed.  Each selection will take
>       you to the Software Download web page; click on any
>       Site listed to download your file to your local disk.
>
> 
>


--------------080902000007020503020205
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Dear all,<br>
<br>
While rereading the protocol draft, I realized that I did a mistake
(forgot to update something).<br>
To be consistent with the time proposal, the packet header should look
like:<br>
<p class="RFCHeading2" style="text-indent: -19.8pt;"><!--[if !supportLists]--><span
 style=""><span style="">1.1 Section 8.1 Heade</span></span>r
Format</p>
<p class="MsoNormal" style="margin-left: 27pt;"><o:p></o:p></p>
<p class="MsoNormal" style="margin-left: 27pt;"><span
 style="font-family: &quot;Courier New&quot;;"><span style="">&nbsp;</span>0<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>1<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>2<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>3<o:p></o:p><br>
<span style="">&nbsp;</span>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
3 4 5 6 7 8 9 0 1<o:p></o:p><br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p><br>
|<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Version Number<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>|<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Length<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>|<o:p></o:p><br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p><br>
|<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>UNIX Secs<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>|<o:p></o:p><br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p><br>
|<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Sequence Number<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>|<o:p></o:p><br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p><br>
|<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="">&nbsp;&nbsp;</span>Source
ID<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>|<o:p></o:p><br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<o:p></o:p></span></p>
<br>
This will be corrected for the next protocol draft version.<br>
<br>
Regards, Benoit.<br>
<br>
<blockquote type="cite" cite="mid400D7901.4090000@cisco.com">
  <meta http-equiv="Content-Type" content="text/html;">
  <title></title>
Dear all,<br>
  <br>
Here is the changes in the new version of the IPFIX protocol draft,
posted today.<br>
  <br>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
  <span style="text-decoration: underline;">New sections:</span><br>
  <pre wrap="">- overview section written
- Vendor Specific Information Element
	New section 8.3.1 "IETF Exclusive Template FlowSet Format"
	New section 8.3.2 "Vendor Specified Template FlowSet Format"
	New section 9.1.1 "IETF Exclusive Options Template FlowSet Format"
	New section 9.1.2 "Vendor Specified Options Template FlowSet Format<span
 style="font-family: &quot;courier new&quot;,monospace;"><span
 style="font-weight: bold;">"
- </span>Metering Process Statistics Option Template
<span style="font-weight: bold;"> 	</span>New section 9.3 "Specific IPFIX Options Templates"
</span><span style="font-family: &quot;courier new&quot;,monospace;"><span
 style="font-weight: bold;">  	</span>New section 9.3.1 "Metering Process Statistics Option Template"
</span><span style="font-family: &quot;Courier New&quot;;">  I've been trying to write down text that IMHO is the WG group consensus, as a starting point</span>
- time synchronization:
	UNIX Secs new definition
	sysUpTime removed from the header format
	New <span style="font-family: &quot;Courier New&quot;;">Section 10 "Export Packet UNIX Secs Computation and Flow Records Times"
</span>	New <span style="font-family: &quot;Courier New&quot;;">Section 10.1 "microsecond precision"
</span>	New <span style="font-family: &quot;Courier New&quot;;">Section 10.2 "nanosecond precision"
</span>	New <span style="font-family: &quot;Courier New&quot;;">Section 10.3 "millisecond precision"
</span>	New <span style="font-family: &quot;Courier New&quot;;">Section 10.4 "multiple precisions"</span><span
 style="font-family: &quot;Courier New&quot;;">
  I've been trying to write down text that IMHO is the WG group consensus, as a starting point
  Note that the example in section 17.1 has been updated with the new change
- A new section on the "</span>Linkage with Information Model" defining the encoding rules and the 
"Reduced Size Encoding of Integral Types". Initial text proposed by Jeff Meyer
	New <span style="font-family: &quot;Courier New&quot;;">Section 11 "</span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;">Linkage with the Information Model</span>"
	New Section 11.1 "Boolean"
	New Section 11.2 "Byte"
	New Section 11.3 "UnsignedByte"
	New Section 11.4 "Short"
	...
	New Section 11.5 "<span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;">Reduced Size Encoding of Integral Types"</span>
  Again, this is a starting point for further discussion.
- A new section 15 Security Considerations.
  Initial proposed by Stewart Bryant. 
	New section 15.1 "IPsec Profile"
	New section 15.1.1 "Selectors"
	New section 15.1.2 "Mode"
	New section 15.1.3 "Key Management"
	New section 15.1.4 "Security Policy"
	New section 15.1.5 "Authentication"
	New section 15.1.6 "Availability"
	New section 15.2 "Network Architecture"
	New section 15.3 "When IPsec is not an Option"
	New section 15.4 "Transport Issues"
	New section 15.5 "Logging an IPFIX Attack"
  Again, this is a starting point for further discussion.
- quick "IANA considerations" section 16, which still needs some more work
- meterstats
  </pre>
  <pre wrap=""><span style="text-decoration: underline;">Updates</span><span
 style="font-family: &quot;Courier New&quot;;">
</span>- Length replaced the Count in the header. Example at the end of the draft is updated.
- Updated the Variable Length Data Type 
  As a consequence, the new term "Information Element" exists in the terminology section
- normative versus informative references</pre>
  <span style="text-decoration: underline;">Editorial changes</span><br>
  <pre wrap="">- "Packet Layout" changed "IPFIX Message Layout"
- latest references: SCTP-PR, INFO_MODEL
- reference to [IPFIX-INFO] instead of "Field Type Definitions" section, which was a section in the NetFlow version 9 draft
- "Header" changed to "Message Header"
<span style="font-family: &quot;Courier New&quot;;">  Note that the example in section 17.1 has been updated with the new change</span>
- changed the section 5.2.3.4 to stream
- removed any NetFlow or NetFlow collector references
- remove the UDP reference (anyway not used in the draft)
- Section 5.2.2 introduces 'SCTP streams,' I'd add "referred to hereafter
      as 'streams;' 'streams' is one of those words which means many different
      things in different contexts.
- Section 5.2.3.2, Source ID:
 &nbsp;change "MUST be kept unique for each such [Observation] domain" into "'MUST be kept unique for each such Observation domain"
- Section 5.2.5. What are "diverting" SID values?  Is it just a typo for "differing?" Corrected!
- Section 5.2.4, Collecting Process: typo in line 2,<span
 style="font-family: monospace;"> </span>s/Collecting Process/Exporting Process/
Corrected.
- Section 5.2.4.  Wouldn't hurt to say SID (Source ID) to remin readers where SID was defined.
- add Ganesh Sadasivan and Stewart Bryant as authors as they prepared the text for Vendor Specific Information Element
- IPFIX Packet Header version changed from 0x0009 to 0x000a
  </pre>
  <br>
As always, your feedback is welcome.<span
 style="font-family: monospace;"><br>
The first sections "</span>open issues" and "action items" have been
updated. Please correct me if I missed some.<br>
Don't forget to also propose some new text when you address an issue ;)<br>
  <br>
To get the draft right, follow the procedure below<br>
  <br>
Regards, Benoit.<br>
  <br>
The file name is draft-ietf-ipfix-protocol-02.txt (IPFIX protocol draft
version 2)<br>
  <br>
To get these files, please do the following...<br>
&nbsp;&nbsp; 1. With a Netscape or Internet Explorer web browser open<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the following URL:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext"
 href="http://www.cisco.com/pcgi-bin/specialaccess.cgi">http://www.cisco.com/pcgi-bin/specialaccess.cgi</a><br>
&nbsp;&nbsp; 2. Enter all your details and at the 'Special Access Code' prompt, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enter in MEANLSKM<br>
&nbsp;&nbsp; 3. Click on the 'Submit' button.&nbsp; This will bring you<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to a web page listing your files for pickup.<br>
&nbsp;&nbsp; 4. Select each file listed.&nbsp; Each selection will take<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; you to the Software Download web page; click on any<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Site listed to download your file to your local disk.<br>
  <br>
  <pre>&nbsp;</pre>
</blockquote>
<br>
</body>
</html>

--------------080902000007020503020205--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 27 03:26:16 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24526
	for <ipfix-archive@lists.ietf.org>; Tue, 27 Jan 2004 03:26:16 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AlO4V-0007iT-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 27 Jan 2004 01:55:43 -0600
Received: from bay3-f27.bay3.hotmail.com ([65.54.169.27] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AlO4U-0007iI-00
	for ipfix@net.doit.wisc.edu; Tue, 27 Jan 2004 01:55:42 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 26 Jan 2004 23:55:41 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Tue, 27 Jan 2004 07:55:40 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] [issue] INFO-28  Reword section 5 "Extending the Information Model"
Date: Mon, 26 Jan 2004 23:55:40 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F27e9okrY71GGy00011279@hotmail.com>
X-OriginalArrivalTime: 27 Jan 2004 07:55:41.0176 (UTC) FILETIME=[F58D5780:01C3E4AA]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

This is an important area for users who wish to use the basic IPFIX 
transport and leverage
the information modeling aspects of ipfix-info.  The current wording does 
not provide a
clear enough set of steps for authors of additional extending informaiton 
models.

-- Jeff Meyer

_________________________________________________________________
There are now three new levels of MSN Hotmail Extra Storage!  Learn more. 
http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 27 05:06:26 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27600
	for <ipfix-archive@lists.ietf.org>; Tue, 27 Jan 2004 05:06:26 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AlPiw-0003do-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 27 Jan 2004 03:41:34 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AlPiv-0003dj-00
	for ipfix@net.doit.wisc.edu; Tue, 27 Jan 2004 03:41:33 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 27 Jan 2004 10:42:14 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i0R9fAhn027222;
	Tue, 27 Jan 2004 10:41:10 +0100 (MET)
Received: from cisco.com (dhcp-ams-cam-avl42-144-254-206-89.cisco.com [144.254.206.89])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA03164;
	Tue, 27 Jan 2004 09:41:20 GMT
Message-ID: <4016323F.9060808@cisco.com>
Date: Tue, 27 Jan 2004 09:41:19 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeff Meyer <inetpix@msn.com>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue]  INFO-26  Section 7 of info-02 should be reworded
References: <BAY3-F36NTXiQD9Eg4400011d3d@hotmail.com>
In-Reply-To: <BAY3-F36NTXiQD9Eg4400011d3d@hotmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 8bit


Jeff Meyer wrote:
> The current section 7 describes in general the benefits of an XML based 
> information model,
> some would say too much.  It does not describe any specific applications 
> of this approach.
> 
> Specifically the ability to serialize as either XML or binary documents, 
> collections of received
> IPFIX flow records is a benefit.  This can be realized with existing 
> open source tools from
> IPDR.  Elaborating on how this connection can be established would be 
> helpful to the
> community, since persisting collected sets of flows is a common task in 
> today's netflow
> deployments.
> 
> -- Jeff Meyer
> 

Jeff

Section 7 contains no information necessary to implement the protocol
and should be deleted.

Assuming that we retain Appendix A, a synopsys of section 7 might be
used in the introduction to that appendix, but I don't think that
you really needs to say any more than "here is the definition
in XML".

If you think that an expanded version of section 7 is useful to
the IETF community, then I think that should go in a seperate
informational draft.

BTW the current intro to Appendix A says:

"The normative status of this appendix versus the section "Flow
Attributes" is a point of discussion.  The "Flow Attributes" section
is simply machine generated from the formal XML document below.  As
such using the formal XML document would seem preferable.  However
historical conventions and IETF's overall level of XML adoption may
lead to selection of the human readable text in the "Flow Attributes"
section as being preferable as normative."

This needs to be replaced with a simple statement saying either:

a) The text in the numeric sections of this draft/RFC is the
    normative text,

or

b) The XML desctiption in this appendix is the normative text.

thereby removing any ambigutity of the status of Appendix A.

- Stewart








> _________________________________________________________________
> Find high-speed ‘net deals — comparison-shop your local providers here. 
> https://broadband.msn.com
> 
> 
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Tue Jan 27 19:51:35 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06724
	for <ipfix-archive@lists.ietf.org>; Tue, 27 Jan 2004 19:51:35 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AldW5-0003t1-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 27 Jan 2004 18:25:13 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AldW4-0003sw-00
	for ipfix@net.doit.wisc.edu; Tue, 27 Jan 2004 18:25:12 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0S0PANA068386
	for <ipfix@net.doit.wisc.edu>; Wed, 28 Jan 2004 01:25:11 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0S0PAeT068385
	for <ipfix@net.doit.wisc.edu>; Wed, 28 Jan 2004 01:25:10 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0S0P8N8068383; Wed, 28 Jan 2004 01:25:10 +0100 (CET)
Received: from [10.1.1.26] (dial02.office [10.1.1.26])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id E4A7EFE53D; Wed, 28 Jan 2004 01:25:05 +0100 (CET)
Date: Wed, 28 Jan 2004 01:25:17 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: ipfix@net.doit.wisc.edu
Cc: bwijnen@lucent.com
Subject: [ipfix] new IPFIX requirements draft
Message-ID: <2147483647.1075253117@[10.1.1.26]>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dear all,

One of the modifications I did for the last version of the requirements
draft was done badly.  Russ Housley complained and I submitted a new version.

As usual, below please find the list of changes from version -14 to the new
version -15 of the IPFIX requirements draft.

Until it gets posted you can preview it at

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

Cheers,

    Juergen
-- 
Juergen Quittek        quittek@ccrle.nec.de        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


=========================
IPFIX Requirements Issues
=========================


========================================================================
31. Bad phrasing in Section 4.3 (issue 26. revisited)
========================================================================
Problem Description:
------------------------------------------------------------------------
In the rephrased section 4.3 (previously numbered 4.2) is some bad
phrasing left.

raised by Russ Housley
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace

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

by

  "The metering process MUST be able to separate flows by the following
   fields of the IP header:"
========================================================================
Status: solution committed
========================================================================



========================================================================
32. Badly phrasing in Section 4.2
========================================================================
Problem Description:
------------------------------------------------------------------------
The first sentence in section 4.2 is obsolete:
  "4.2.  Interfaces

      The metering process MUST be able to separate flows  by the following
      fields of the IP header: The metering process MUST be able to
      separate flows by the incoming interface or by the outgoing interface
      or by both of them."

raised by Russ Housley
========================================================================
Suggested solution:
------------------------------------------------------------------------
remove first sentence.
========================================================================
Status: solution committed
========================================================================


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 03:14:28 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19214
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 03:14:28 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AlkXr-0001SX-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 01:55:31 -0600
Received: from bay3-f35.bay3.hotmail.com ([65.54.169.35] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AlkXq-0001SS-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 01:55:30 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 27 Jan 2004 23:55:29 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Wed, 28 Jan 2004 07:55:29 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] [issue] INFO-29  Namespace definitions may need IANA considerations
Date: Tue, 27 Jan 2004 23:55:29 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F35Tzvb5YI9IJs0001e87a@hotmail.com>
X-OriginalArrivalTime: 28 Jan 2004 07:55:29.0806 (UTC) FILETIME=[19302AE0:01C3E574]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

The current info-model-02 specification contains references to XML type 
names and semantics borrowed directly from the XML-Schema specification as 
well as extensions.

Currently these extensions borrow from existing work of IPDR as well as 
newly identified types currently specific to IPFIX.

There are a few ways to address this.

The following e-mail thread discusses the options and opinion of this editor 
as well as opinions from Andrew Norton who is involved in IETF's and IANA's 
work in utilizing XML in RFC's.


Jeff,

It would seem that this is all a matter of "taste" as any of these options 
technically work.  Personally I would go with option 3; though it requires 
more coordination between organizations, to an outsider it would seem more 
cohesive.

There is a practical difference between option 1 and option 3 in terms of 
setting the standard.  With option 3, if IPDR upgrades their standard, the 
IPFIX group needs to do nothing to incorporate the changes.  However, with 
option 1, IPFIX will have to standardize a new schema and issue new RFC's.

-andy

Jeff Meyer wrote:
    Hi Andy,

I wanted to get your opinion on extending the XML-Schema type system for 
some specific information modeling requirements encountered by the IPFIX 
working group.

IPFIX currently reuses about 15 types from XML-Schema directly, however 
there are several types which are worthwile to distinguish from an IPFIX 
persepective which are not defined by XML-Schema.

These include types to identify timestamps of specific resolution (e.g. 
mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and one for 
UUIDs.

Today most of these extension types are defined in the public NDM-U 3.1.1 
specification from the industry consortium called IPDR.org.  There are a 
couple which are not are related to the high resolution timestamps (uSec and 
nSec).

The NDM-U 3.1.1 specificaiton is avaiable at 
http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically section 
A.4.4.

The IPFIX-Info reference is available at:

http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#anchor4


This is a link to the specific secion in the HTML format of the info model 
based on RFC2629.


The quesion at hand is whether to follow one of the following 3 options:

   1. have a single XML-Schema which defines the extension types relevant to 
IPFIX and contained in the IPFIX namespace
   2. reference the existing types targeted by IPDR and add only the new 
types specific to the IPFIX Schema
   3. petition IPDR to define the remaining two IPFIX types for timestamps 
in their upcoming 3.5 specification (likely timeframe Feb. or March)

I get the impression from IPFIX discussions that referencing IPDR is 
something that some vocal participants find objectionable, i.e. they would 
prefer to see option 1.

My personal preference would be to go with option 3 or 2.  I believe 3 is 
doable and would reduce the number of places where people have to look for 
things.  Option 1 I see as creating some confusion in the space, but 
ultimately addressable through XSL or other mapping functions, if that's 
what it takes to get consensus.


Any guidance on your part would be appreciated.

Regards,

Jeff Meyer

_________________________________________________________________
Get a FREE online virus check for your PC here, from McAfee. 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 03:22:45 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19861
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 03:22:45 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AlkP8-00016p-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 01:46:30 -0600
Received: from bay3-f7.bay3.hotmail.com ([65.54.169.7] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AlkP7-00016j-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 01:46:29 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 27 Jan 2004 23:46:28 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Wed, 28 Jan 2004 07:46:28 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: stbryant@cisco.com
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-26 Section 7 of info-02 should be reworded
Date: Tue, 27 Jan 2004 23:46:28 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F7q6YZpdR3tDIC0002919e@hotmail.com>
X-OriginalArrivalTime: 28 Jan 2004 07:46:28.0719 (UTC) FILETIME=[D6ACD7F0:01C3E572]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Stewart,

  I feel section 7 describes a departure from the current approach in many 
RFC's to pay limited attention to addressing the information modeling 
aspects of various interchange mechanisms and describes the rationale for 
taking a more focused approach.

  The ability to store collections of information transmitted by IPFIX in an 
existing open format is also benefiicial and simply not addressing it seems 
to increase the likelihood of unnecessary rework.

  Regarding the normative status of the base XML formal definition vs. the 
alternate presentation format provided in section 6, I agree this is an 
issue.  I was awaiting feedback from Andrew Norton who is involved with IANA 
administration of XML namespaces to respond to e-mail.

  I have gotten his response and will post the normative status as a 
separate issue.

Regards,

  Jeff Meyer


>From: Stewart Bryant <stbryant@cisco.com>
>Reply-To: stbryant@cisco.com
>To: Jeff Meyer <inetpix@msn.com>
>CC: ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue]  INFO-26  Section 7 of info-02 should be 
>reworded
>Date: Tue, 27 Jan 2004 09:41:19 +0000
>
>
>Jeff Meyer wrote:
>>The current section 7 describes in general the benefits of an XML based 
>>information model,
>>some would say too much.  It does not describe any specific applications 
>>of this approach.
>>
>>Specifically the ability to serialize as either XML or binary documents, 
>>collections of received
>>IPFIX flow records is a benefit.  This can be realized with existing open 
>>source tools from
>>IPDR.  Elaborating on how this connection can be established would be 
>>helpful to the
>>community, since persisting collected sets of flows is a common task in 
>>today's netflow
>>deployments.
>>
>>-- Jeff Meyer
>>
>
>Jeff
>
>Section 7 contains no information necessary to implement the protocol
>and should be deleted.
>
>Assuming that we retain Appendix A, a synopsys of section 7 might be
>used in the introduction to that appendix, but I don't think that
>you really needs to say any more than "here is the definition
>in XML".
>
>If you think that an expanded version of section 7 is useful to
>the IETF community, then I think that should go in a seperate
>informational draft.
>
>BTW the current intro to Appendix A says:
>
>"The normative status of this appendix versus the section "Flow
>Attributes" is a point of discussion.  The "Flow Attributes" section
>is simply machine generated from the formal XML document below.  As
>such using the formal XML document would seem preferable.  However
>historical conventions and IETF's overall level of XML adoption may
>lead to selection of the human readable text in the "Flow Attributes"
>section as being preferable as normative."
>
>This needs to be replaced with a simple statement saying either:
>
>a) The text in the numeric sections of this draft/RFC is the
>    normative text,
>
>or
>
>b) The XML desctiption in this appendix is the normative text.
>
>thereby removing any ambigutity of the status of Appendix A.
>
>- Stewart
>
>
>
>
>
>
>
>
>>_________________________________________________________________
>>Find high-speed ‘net deals — comparison-shop your local providers here. 
>>https://broadband.msn.com
>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>

_________________________________________________________________
Scope out the new MSN Plus Internet Software — optimizes dial-up to the max! 
   http://join.msn.com/?pgmarket=en-us&page=byoa/plus&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 03:42:46 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21043
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 03:42:46 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Alko5-00023l-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 02:12:17 -0600
Received: from bay3-f42.bay3.hotmail.com ([65.54.169.42] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Alko4-00023a-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 02:12:16 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 28 Jan 2004 00:12:15 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Wed, 28 Jan 2004 08:12:15 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] [issue] INFO-30  Normative status of section 6 vs. Appendix A
Date: Wed, 28 Jan 2004 00:12:15 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F42T9KP4vtAsny0000d367@hotmail.com>
X-OriginalArrivalTime: 28 Jan 2004 08:12:15.0511 (UTC) FILETIME=[70A29270:01C3E576]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

The info-02 draft states this as an open issue.  It is time to close it.

Providing a formal specification reusing industry standard XML has benefits 
outlined in section 7. The formal specificaiton represent a departure from 
much of the RFC work, with the notable exception of activities like SNMP 
which adopted the ASN.1 based MIBs as a means of formals specification.  A 
current example not following any formal model today is work w/in Diameter, 
or previously work done in RADIUS.

Hence the recommendation is to make Appendix A normative.

Alternatively one could argue that to make the lowest possible barrier to 
extension by others to simply define the text base components, one could 
manually transcribe this to XML-Schema as a manual process following the 
example in appendix A.

-- Jeff

_________________________________________________________________
Check out the new MSN 9 Dial-up — fast & reliable Internet access with prime 
features! http://join.msn.com/?pgmarket=en-us&page=dialup/home&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 06:05:02 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25156
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 06:05:01 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Aln03-0006xK-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 04:32:47 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Aln02-0006xF-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 04:32:46 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 28 Jan 2004 11:33:26 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i0SAWM38028077;
	Wed, 28 Jan 2004 11:32:22 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp79.cisco.com [10.61.64.79])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA20154;
	Wed, 28 Jan 2004 10:32:43 GMT
Message-ID: <40178FC9.6000805@cisco.com>
Date: Wed, 28 Jan 2004 10:32:41 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeff Meyer <inetpix@msn.com>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-30  Normative status of section 6 vs. Appendix
 A
References: <BAY3-F42T9KP4vtAsny0000d367@hotmail.com>
In-Reply-To: <BAY3-F42T9KP4vtAsny0000d367@hotmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 8bit



Jeff Meyer wrote:
> The info-02 draft states this as an open issue.  It is time to close it.
> 
> Providing a formal specification reusing industry standard XML has 
> benefits outlined in section 7. The formal specificaiton represent a 
> departure from much of the RFC work, with the notable exception of 
> activities like SNMP which adopted the ASN.1 based MIBs as a means of 
> formals specification.  A current example not following any formal model 
> today is work w/in Diameter, or previously work done in RADIUS.
> 
> Hence the recommendation is to make Appendix A normative.
> 

I disagree and ask the WG chairs to check WG concensus.

Stewart

> Alternatively one could argue that to make the lowest possible barrier 
> to extension by others to simply define the text base components, one 
> could manually transcribe this to XML-Schema as a manual process 
> following the example in appendix A.
> 
> -- Jeff
> 
> _________________________________________________________________
> Check out the new MSN 9 Dial-up — fast & reliable Internet access with 
> prime features! http://join.msn.com/?pgmarket=en-us&page=dialup/home&ST=1
> 
> 
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 06:52:51 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27074
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 06:52:51 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Alo4f-0001yz-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 05:41:37 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Alo4e-0001yq-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 05:41:36 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0SBfVNA001178
	for <ipfix@net.doit.wisc.edu>; Wed, 28 Jan 2004 12:41:33 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0SBfUYO001175
	for <ipfix@net.doit.wisc.edu>; Wed, 28 Jan 2004 12:41:30 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0SBfTN8001173; Wed, 28 Jan 2004 12:41:30 +0100 (CET)
Received: from [10.1.1.171] (n-quittek.office [10.1.1.171])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 92C38FE570; Wed, 28 Jan 2004 12:41:28 +0100 (CET)
Date: Wed, 28 Jan 2004 12:41:42 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: plonka@doit.wisc.edu, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] IPFIX status, propose not meeting at 59th IETF (Seoul)
Message-ID: <2147483647.1075293702@[10.1.1.171]>
In-Reply-To: <20040108161700.A13837@doit.wisc.edu>
References:  <20040108161700.A13837@doit.wisc.edu>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Dave,

The mailing list is very active and there are still many open issues.

I doubt that we will solve all of them within a month, although
the issues are not fundamental (except the decision on the IPFIX
default transport protocol which IMHO has not yet been made in a
clearly visible way).

So, I guess we would have a lot of discussion points in Seoul,
particularly concerning IPFIX transport (how to handle reconnection
after temporary disconnection, error recovery if sequence counters
fail, protection against DoS acctacks, ... , and the TCP section
in the protocol draft is still empty and needs to be written and
discussed).

So, my guess is that there is indeed a need for an IPFIX session
at Seoul.

Thanks,

    Juergen


--On 08.01.2004 16:17 Uhr -0600 Dave Plonka wrote:

> IPFIXers,
>
> Please review the status update (thanks to Nevil) below and
> this proposal from Nevil and I:
>
> At this stage there don't appear to be any 'show-stopper' issues, which
> raises the question, "Do we need to hold an IPFIX meeting in Seoul?"
>
> Your WG co-chairs feel that what's needed is concentrated work to
> finish the four IPFIX drafts so that the protocol can be implemented
> from the definition.  It would be great to get the drafts to WG last
> call by late February and finished by the end of March.
>
> How do WG members feel about this proposal?
>
> If we were to meet in Seoul, what are the main issues we'd need to
> discuss?  It would be quite a challenge for either of us to attend in
> Seoul, so any such issues would have to be compelling.
>
> Cheers,
> Dave & Nevil
>
> --
>
>    IPFIX WG: Status as of 9 Jan 04
>    -------------------------------
>
>    1. WG Drafts being considered by IESG
>
>       - Requirements Draft, version 13
>       - Evaluation draft:
>         Simon is revising following comments from Bert (Ops AD)
>
>    2. Milestones
>
>       Have been reivsed as discussed at Minneapolis meeting.  Looking
>       at them on the IPFIX charter page, I see that I've left out the
>       PROTOCOL draft - that goes along with the ARCHITECTURE,
>       INFO_MODEL and APPLICABILITY drafts.
>
>       Those four drafts have a milestone date saying they'll be
>       submitted to IESG by May 04.  Note that we set that date assuming
>       that they'd all be in their final stages by the next meeting
>       (Seoul, 29 Feb - 5 Mar 04).  Since other WGs (e.g. PSAMP) are
>       waiting for them, we would be good to get them done before that!
>
>    3. Current drafts
>
>       These are the four referred to in capitals above.  There's been
>       quite a lot of mailing-list discussion of various issues relating
>       to PROTOCOL and INFO_MODEL in the last month or so, which is
>       great.  Also, that discussion has been fairly well-structured,
>       i.e. we've managed to keep the issues separate by using their
>       issue number in the subject lines.
>
> --
> plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 06:55:58 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27158
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 06:55:58 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Alo7k-0002Gw-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 05:44:48 -0600
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Alo7j-0002Gr-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 05:44:47 -0600
Received: from sj-core-4.cisco.com (171.68.223.138)
  by sj-iport-5.cisco.com with ESMTP; 28 Jan 2004 03:44:53 -0800
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0SBignG021696;
	Wed, 28 Jan 2004 03:44:43 -0800 (PST)
Received: from cisco.com (ams-clip-vpn-dhcp79.cisco.com [10.61.64.79])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA22495;
	Wed, 28 Jan 2004 11:44:41 GMT
Message-ID: <4017A0A6.2020907@cisco.com>
Date: Wed, 28 Jan 2004 11:44:38 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juergen Quittek <quittek@ccrle.nec.de>, bwijnen@lucent.com,
        allison mankin <mankin@isi.edu>
CC: ipfix@net.doit.wisc.edu
Subject: [ipfix] IPFIX requirements - security
References: <2147483647.1075253117@[10.1.1.26]>
In-Reply-To: <2147483647.1075253117@[10.1.1.26]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

I believe that the security requirements (below) which were
enhanced by the IESG are an unreasonable burden on many
implementations.

The new requirements lack a measure of appropriateness which
needs to be incorporated in the definition.

For example there is no point in providing greater
confidentiality in the IPFIX protocol than exists at the
observation point itself.

There is no point in providing a level of integrity or
authenticity that exceeds the requirements of the collecting
application.

Setting the baseline for operation over the public Internet
leads to the inevitable conclusion that IPFIX MUST be run
over IPsec, but that is absurd in situations where the
network design precludes the possibility of data leakage
(for example where the IPFIX traffic is carried over a
private management network).

The net result of setting the bar at this level will be
either late and unnecessarily costly deployment of IPFIX,
or (more likely) the widespread deployment of non-compliant
IPFIX, thereby bringing the RFC into disrepute.

Section 6.3.3 should therefore be reworded to something
of the following form:

IPFIX data transferred from an exporting process to a
collecting process MUST NOT degrade the confidentiality of
the packet flows at the observation point.

The method of transferring IPFIX data from the exporting
process to the collecting process MUST provide the level
of data integrity required by the collecting application.

The authenticity of IPFIX data transferred from an exporting
process to a collecting process MUST be sufficient to meet
the application needs at the collector.

- Stewart


Original text for reference:

====================

6.3.3.  Security

    Confidentiality of IPFIX data transferred from an exporting process
    to a collecting process MUST be ensured.

    Integrity of IPFIX data transferred from an exporting process to a
    collecting process MUST be ensured.

    Authenticity of IPFIX data transferred from an exporting process to a
    collecting process MUST be ensured.

=====================

10.  Security Considerations

    An IPFIX protocol must be capable of transporting data over the
    public Internet.  Therefore it cannot be excluded that an attacker
    captures or modifies packets or inserts additional packets.


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 11:56:15 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11957
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 11:56:14 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Alsmu-0003Xx-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 10:43:36 -0600
Received: from bay3-f19.bay3.hotmail.com ([65.54.169.19] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Alsmt-0003Xr-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 10:43:35 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 28 Jan 2004 08:43:34 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Wed, 28 Jan 2004 16:43:34 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: stbryant@cisco.com
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs. Appendix A
Date: Wed, 28 Jan 2004 08:43:34 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F19BqsZKnRkgTR0008b18d@hotmail.com>
X-OriginalArrivalTime: 28 Jan 2004 16:43:34.0443 (UTC) FILETIME=[DEB417B0:01C3E5BD]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Stewart,

  Any rationale here, or you just have an aversion to anything with XML in 
it?

-- Jeff


>From: Stewart Bryant <stbryant@cisco.com>
>Reply-To: stbryant@cisco.com
>To: Jeff Meyer <inetpix@msn.com>
>CC: ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-30  Normative status of section 6 vs. 
>Appendix A
>Date: Wed, 28 Jan 2004 10:32:41 +0000
>
>
>
>Jeff Meyer wrote:
>>The info-02 draft states this as an open issue.  It is time to close it.
>>
>>Providing a formal specification reusing industry standard XML has 
>>benefits outlined in section 7. The formal specificaiton represent a 
>>departure from much of the RFC work, with the notable exception of 
>>activities like SNMP which adopted the ASN.1 based MIBs as a means of 
>>formals specification.  A current example not following any formal model 
>>today is work w/in Diameter, or previously work done in RADIUS.
>>
>>Hence the recommendation is to make Appendix A normative.
>>
>
>I disagree and ask the WG chairs to check WG concensus.
>
>Stewart
>
>>Alternatively one could argue that to make the lowest possible barrier to 
>>extension by others to simply define the text base components, one could 
>>manually transcribe this to XML-Schema as a manual process following the 
>>example in appendix A.
>>
>>-- Jeff
>>
>>_________________________________________________________________
>>Check out the new MSN 9 Dial-up — fast & reliable Internet access with 
>>prime features! http://join.msn.com/?pgmarket=en-us&page=dialup/home&ST=1
>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>

_________________________________________________________________
Let the new MSN Premium Internet Software make the most of your high-speed 
experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 13:28:21 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18616
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 13:28:21 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AluAa-0006F5-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 12:12:08 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AluAZ-0006Ez-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 12:12:08 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 28 Jan 2004 19:12:47 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i0SIBi38017097;
	Wed, 28 Jan 2004 19:11:44 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp79.cisco.com [10.61.64.79])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA09116;
	Wed, 28 Jan 2004 18:12:03 GMT
Message-ID: <4017FB72.5050000@cisco.com>
Date: Wed, 28 Jan 2004 18:12:02 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeff Meyer <inetpix@msn.com>
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs. Appendix
 A
References: <BAY3-F19BqsZKnRkgTR0008b18d@hotmail.com>
In-Reply-To: <BAY3-F19BqsZKnRkgTR0008b18d@hotmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 8bit



Jeff Meyer wrote:

> Stewart,
> 
>  Any rationale here, or you just have an aversion to anything with XML 
> in it?

Yes.

Probably zero exporter implementors can use the XML as a direct
coding input, and certainly not all collectors implementors can.

Implementors MUST code from the normative text, and the XML is
harder to read than the table.

Therefore the normative text should be the table.

If you want to produce an XML definition as a courtesy to implementors
you can should produce a seperate informational draft.

Clearly you and I have different views on this, but as a WG draft
the info model MUST reflect the consensus of the WG, hence my
request for the chairs to test the WG consensus.

- Stewart

> 
> -- Jeff
> 
> 
>> From: Stewart Bryant <stbryant@cisco.com>
>> Reply-To: stbryant@cisco.com
>> To: Jeff Meyer <inetpix@msn.com>
>> CC: ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] [issue] INFO-30  Normative status of section 6 
>> vs. Appendix A
>> Date: Wed, 28 Jan 2004 10:32:41 +0000
>>
>>
>>
>> Jeff Meyer wrote:
>>
>>> The info-02 draft states this as an open issue.  It is time to close it.
>>>
>>> Providing a formal specification reusing industry standard XML has 
>>> benefits outlined in section 7. The formal specificaiton represent a 
>>> departure from much of the RFC work, with the notable exception of 
>>> activities like SNMP which adopted the ASN.1 based MIBs as a means of 
>>> formals specification.  A current example not following any formal 
>>> model today is work w/in Diameter, or previously work done in RADIUS.
>>>
>>> Hence the recommendation is to make Appendix A normative.
>>>
>>
>> I disagree and ask the WG chairs to check WG concensus.
>>
>> Stewart
>>
>>> Alternatively one could argue that to make the lowest possible 
>>> barrier to extension by others to simply define the text base 
>>> components, one could manually transcribe this to XML-Schema as a 
>>> manual process following the example in appendix A.
>>>
>>> -- Jeff
>>>
>>> _________________________________________________________________
>>> Check out the new MSN 9 Dial-up — fast & reliable Internet access 
>>> with prime features! 
>>> http://join.msn.com/?pgmarket=en-us&page=dialup/home&ST=1
>>>
>>>
>>> -- 
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>> message body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>
> 
> _________________________________________________________________
> Let the new MSN Premium Internet Software make the most of your 
> high-speed experience. 
> http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
> 
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 18:07:53 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06006
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 18:07:53 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AlyN7-0006Bt-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 16:41:21 -0600
Received: from bay3-f27.bay3.hotmail.com ([65.54.169.27] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AlyN6-0006Bn-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 16:41:20 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 28 Jan 2004 14:41:19 -0800
Received: from 216.113.168.128 by by3fd.bay3.hotmail.msn.com with HTTP;
	Wed, 28 Jan 2004 22:41:18 GMT
X-Originating-IP: [216.113.168.128]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: stbryant@cisco.com
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs. Appendix A
Date: Wed, 28 Jan 2004 14:41:18 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F276YHkidcDjoY0000002e@hotmail.com>
X-OriginalArrivalTime: 28 Jan 2004 22:41:19.0262 (UTC) FILETIME=[D8BB8BE0:01C3E5EF]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Stewart,

  With the use of XSL stylesheets the XML style informaiton model could be 
transformed automatically into any set of text one would want, e.g. IOS 
commands to enable flags, HTML tables for presentation, RFC2629 entries in 
an RFC document, etc.  For a discussion and example of using free XSL tools 
to process this you can see 
http://www.ipdr.org/documents/ipfix/infomodel/README.html.

  Hence even without direct connection making XML normative could save 
people a lot of manual transcription errors.

  As the body of section 6 is also machine generated, it is would be in 
synch with the normative format and also address your human readability 
concerns.  Hence those who wish can take a "business as usual" approach to 
specifications as loosely structured prose.

  Conversely, just using arbitrary prose (or even loosely structured prose) 
implies that automated processing of the content is much more difficult, I 
guess a determined perl hack could probably work something out until the 
next informal prose based spec came along.

  So, it would seem you're eager to remove something which is beneficial to 
some, and can be ignored by others and is well specified, rather than 
arguing in favor of some alternate approach and set of benefits which are 
somehow precluded by the XML option.

  Take a look at Nevil's RFC evaluating the AAA landscape, 
http://www.ietf.org/rfc/rfc2924.txt, in particular look at the last 
paragraph in section 8.2.  XML-Schema is now stable and ignoring its 
benefits seems rather short sighted.

-- Jeff


>From: Stewart Bryant <stbryant@cisco.com>
>Reply-To: stbryant@cisco.com
>To: Jeff Meyer <inetpix@msn.com>
>CC: ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs. 
>Appendix A
>Date: Wed, 28 Jan 2004 18:12:02 +0000
>
>
>
>Jeff Meyer wrote:
>
>>Stewart,
>>
>>  Any rationale here, or you just have an aversion to anything with XML in 
>>it?
>
>Yes.
>
>Probably zero exporter implementors can use the XML as a direct
>coding input, and certainly not all collectors implementors can.
>
>Implementors MUST code from the normative text, and the XML is
>harder to read than the table.
>
>Therefore the normative text should be the table.
>
>If you want to produce an XML definition as a courtesy to implementors
>you can should produce a seperate informational draft.
>
>Clearly you and I have different views on this, but as a WG draft
>the info model MUST reflect the consensus of the WG, hence my
>request for the chairs to test the WG consensus.
>
>- Stewart
>
>>
>>-- Jeff
>>
>>
>>>From: Stewart Bryant <stbryant@cisco.com>
>>>Reply-To: stbryant@cisco.com
>>>To: Jeff Meyer <inetpix@msn.com>
>>>CC: ipfix@net.doit.wisc.edu
>>>Subject: Re: [ipfix] [issue] INFO-30  Normative status of section 6 vs. 
>>>Appendix A
>>>Date: Wed, 28 Jan 2004 10:32:41 +0000
>>>
>>>
>>>
>>>Jeff Meyer wrote:
>>>
>>>>The info-02 draft states this as an open issue.  It is time to close it.
>>>>
>>>>Providing a formal specification reusing industry standard XML has 
>>>>benefits outlined in section 7. The formal specificaiton represent a 
>>>>departure from much of the RFC work, with the notable exception of 
>>>>activities like SNMP which adopted the ASN.1 based MIBs as a means of 
>>>>formals specification.  A current example not following any formal model 
>>>>today is work w/in Diameter, or previously work done in RADIUS.
>>>>
>>>>Hence the recommendation is to make Appendix A normative.
>>>>
>>>
>>>I disagree and ask the WG chairs to check WG concensus.
>>>
>>>Stewart
>>>
>>>>Alternatively one could argue that to make the lowest possible barrier 
>>>>to extension by others to simply define the text base components, one 
>>>>could manually transcribe this to XML-Schema as a manual process 
>>>>following the example in appendix A.
>>>>
>>>>-- Jeff
>>>>
>>>>_________________________________________________________________
>>>>Check out the new MSN 9 Dial-up — fast & reliable Internet access with 
>>>>prime features! 
>>>>http://join.msn.com/?pgmarket=en-us&page=dialup/home&ST=1
>>>>
>>>>
>>>>--
>>>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>>>>body
>>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>"unsubscribe ipfix" in message body
>>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>>
>>>
>>
>>_________________________________________________________________
>>Let the new MSN Premium Internet Software make the most of your high-speed 
>>experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
>>
>>
>>
>
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/

_________________________________________________________________
Check out the new MSN 9 Dial-up — fast & reliable Internet access with prime 
features! http://join.msn.com/?pgmarket=en-us&page=dialup/home&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 19:27:35 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09020
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 19:27:34 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Alzif-0000oj-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 18:07:41 -0600
Received: from mailhost2.auckland.ac.nz ([130.216.191.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Alzie-0000m1-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 18:07:40 -0600
Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id i0T06oc5023687;
	Thu, 29 Jan 2004 13:06:50 +1300 (NZDT)
Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP
	id EF28C33F60; Thu, 29 Jan 2004 13:06:49 +1300 (NZDT)
Received: from mailhost.auckland.ac.nz ([127.0.0.1])
 by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 00715-11; Thu, 29 Jan 2004 13:06:38 +1300 (NZDT)
Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP
	id E7BCC33ED4; Thu, 29 Jan 2004 13:06:38 +1300 (NZDT)
Received: (from apache@localhost)
	by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id i0T027K19877;
	Thu, 29 Jan 2004 13:02:07 +1300
Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz
	[130.216.4.167]) by webmail.auckland.ac.nz (Horde) with HTTP for
	<jbro111@webmail.auckland.ac.nz>; Thu, 29 Jan 2004 13:02:07 +1300
Message-ID: <1075334527.09aa8c46d3ec3@webmail.auckland.ac.nz>
Date: Thu, 29 Jan 2004 13:02:07 +1300
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: Jeff Meyer <inetpix@msn.com>
Cc: stbryant@cisco.com, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.
	Appendix A
References: <BAY3-F276YHkidcDjoY0000002e@hotmail.com>
In-Reply-To: <BAY3-F276YHkidcDjoY0000002e@hotmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  130.216.4.167
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Stewart and Jeff:

>   With the use of XSL stylesheets the XML style informaiton model could be
> transformed automatically into any set of text one would want, e.g. IOS
> commands to enable flags, HTML tables for presentation, RFC2629 entries in
> an RFC document, etc.  For a discussion and example of using free XSL tools
> to process this you can see
> http://www.ipdr.org/documents/ipfix/infomodel/README.html.

Jeff's right in saying that XML is becoming more widely used within the
IETF, as evidenced by RFC 2629 and the fact that more WGs (espcially
in the Applications Area) are using it.

However, RFC 2629 explicitly says it doesn't address "IETF politics"
issues.  My take on that is that the text in section 6 of the Info Model
draft is the normative version; Appendix A gives the xml because people
may find it useful, but if they use it they should check that it really
does match the (normative) text version.

As for IPFIX WG consensus on this, in my view the document editors
are free to use whatever tools they need to produce the actual drafts.
Furthermore, including the xml as an appendix allows other people to
use the xml for other purposes, which (I guess) is why the editors
appended it to the draft.

Does that make the situation clearer?

-----------------------------------------------------------------------
   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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 19:35:08 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09259
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 19:35:08 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AlzwS-00017n-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 18:21:56 -0600
Received: from mailhost2.auckland.ac.nz ([130.216.1.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AlzwR-00017h-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 18:21:55 -0600
Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61])
	by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id i0T0Lqc5029513
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 13:21:52 +1300 (NZDT)
Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP id A137B33E6C
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 13:21:52 +1300 (NZDT)
Received: from mailhost.auckland.ac.nz ([127.0.0.1])
 by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 05272-13 for <ipfix@net.doit.wisc.edu>;
 Thu, 29 Jan 2004 13:21:39 +1300 (NZDT)
Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146])
	by mailhost.auckland.ac.nz (Postfix) with ESMTP id B496A33F5A
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 13:21:38 +1300 (NZDT)
Received: (from apache@localhost)
	by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id i0T0H7i20179
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 13:17:07 +1300
Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz
	[130.216.4.167]) by webmail.auckland.ac.nz (Horde) with HTTP for
	<jbro111@webmail.auckland.ac.nz>; Thu, 29 Jan 2004 13:17:07 +1300
Message-ID: <1075335427.b2e7043660e53@webmail.auckland.ac.nz>
Date: Thu, 29 Jan 2004 13:17:07 +1300
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: Transport protocol(s) for IPFIX
References: <BAY3-F36NTXiQD9Eg4400011d3d@hotmail.com>
	<4016323F.9060808@cisco.com>
In-Reply-To: <4016323F.9060808@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  130.216.4.167
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit


Hello all:

Following a long-running discussion between the Transport ADs and
some IPFIX WG members, we have the following test proposed for
the IPFIX protocol draft:


Section 5.x Transport Compliance and Transport Usage

  We must differentiate between what must be implemented (so that
  operators can interoperably deploy compliant implementations
  from different vendors) and what should or could be used in
  various operational environments. We must also make sure that ALL
  implementations can operate in a congention-aware and congestion
  avoiding mode.
  
  SCTP MUST be implemented by all compliant implementations.
  UDP and TCP MAY also be implemented by compliant implementations.

  SCTP SHOULD be used in deployments where exporters and collectors
  are communicating over links which are susceptible to congestion.

  TCP MAY be used in deployments where exporters and collectors
  communicate over links which are suscepible to congestion, but SCTP
  is preferred, due to its ability to limit back pressure on exporters
  (especially when using PR-SCTP) and its message vs. stream orientation.

  Other non-congestion aware protocols (like UDP) MAY be used in
  deployments where exporters and collectors always communicate over
  dedicated links which are not susceptible to congestion.
 

The 'MUST implement SCTP' reflects the WG consensus from our last
meeting in Minneapolis; seems to me that the challenge for WG 
members now is to write text for the 'how to implement IPFIX
on SCTP/TCP/UDP' sections of the protocol draft, and to work
on implementations.

Of course we don't have to have an implementation before the IPFIX
drafts are published, but having one (or better, two!) would help
things along.

Comments, suggestions, .. ?

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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Wed Jan 28 23:07:03 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17050
	for <ipfix-archive@lists.ietf.org>; Wed, 28 Jan 2004 23:07:03 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Am3Fg-0007QN-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jan 2004 21:54:00 -0600
Received: from bay3-f32.bay3.hotmail.com ([65.54.169.32] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Am3Ff-0007QH-00
	for ipfix@net.doit.wisc.edu; Wed, 28 Jan 2004 21:53:59 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 28 Jan 2004 19:53:58 -0800
Received: from 216.113.168.128 by by3fd.bay3.hotmail.msn.com with HTTP;
	Thu, 29 Jan 2004 03:53:58 GMT
X-Originating-IP: [216.113.168.128]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: n.brownlee@auckland.ac.nz
Cc: stbryant@cisco.com, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A
Date: Wed, 28 Jan 2004 19:53:58 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F32pY5GT9IeV3j00004303@hotmail.com>
X-OriginalArrivalTime: 29 Jan 2004 03:53:58.0876 (UTC) FILETIME=[865579C0:01C3E61B]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Nevil,

  My only contention would be that I did not do any direct data entry for 
section 6.  I.e. I wrote the XML-Schema ran it through the publicly 
available stylesheet and free transform engine and pasted it into the doc.

  Certainly it would be my hope that authors of additional information 
models to be carried over IPFIX would follow the same process, because then 
I can simply take their XML-Schema spec and use it in a variety of tools.  
If I only get text, then I have the tedious prospect of transcribing it.  If 
equipment providers favor a manual transcription process, it is certainly 
not precluded.

  My understanding was that PSAMP might be using the XML technique today, I 
believe it was Juergen who asked about the tools and I passed along the 
pointer.

  If it is politically simpler to call section 6 normative but indicate that 
authors of new models SHOULD create an XML-Schema model and MAY machine 
translate these models to create the normative text, then I could live with 
such a compromise.

  Simply excising this information as Stewart seems to be advocating seems 
like a step backwards and I'm at a loss to see any benefit from that.

Regards,

  Jeff Meyer


>From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
>To: Jeff Meyer <inetpix@msn.com>
>CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 
>vs.Appendix A
>Date: Thu, 29 Jan 2004 13:02:07 +1300
>
>Stewart and Jeff:
>
> >   With the use of XSL stylesheets the XML style informaiton model could 
>be
> > transformed automatically into any set of text one would want, e.g. IOS
> > commands to enable flags, HTML tables for presentation, RFC2629 entries 
>in
> > an RFC document, etc.  For a discussion and example of using free XSL 
>tools
> > to process this you can see
> > http://www.ipdr.org/documents/ipfix/infomodel/README.html.
>
>Jeff's right in saying that XML is becoming more widely used within the
>IETF, as evidenced by RFC 2629 and the fact that more WGs (espcially
>in the Applications Area) are using it.
>
>However, RFC 2629 explicitly says it doesn't address "IETF politics"
>issues.  My take on that is that the text in section 6 of the Info Model
>draft is the normative version; Appendix A gives the xml because people
>may find it useful, but if they use it they should check that it really
>does match the (normative) text version.
>
>As for IPFIX WG consensus on this, in my view the document editors
>are free to use whatever tools they need to produce the actual drafts.
>Furthermore, including the xml as an appendix allows other people to
>use the xml for other purposes, which (I guess) is why the editors
>appended it to the draft.
>
>Does that make the situation clearer?
>
>-----------------------------------------------------------------------
>    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:majordomo@net.doit.wisc.edu and say "help" in message 
>body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/

_________________________________________________________________
Learn how to choose, serve, and enjoy wine at Wine @ MSN. 
http://wine.msn.com/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 05:33:36 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12019
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 05:33:36 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Am8tN-0002fK-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 03:55:21 -0600
Received: from syd-iport-1.cisco.com ([64.104.193.196])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Am8tM-0002fF-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 03:55:20 -0600
Received: from bej-core-1.cisco.com (64.104.160.31)
  by syd-iport-1.cisco.com with ESMTP; 29 Jan 2004 02:03:11 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by bej-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0T9qxfK006218;
	Thu, 29 Jan 2004 17:53:35 +0800 (CST)
Received: from cisco.com (ams-clip-vpn-dhcp79.cisco.com [10.61.64.79])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA04567;
	Thu, 29 Jan 2004 09:44:21 GMT
Message-ID: <4018D5F4.5030209@cisco.com>
Date: Thu, 29 Jan 2004 09:44:20 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeff Meyer <inetpix@msn.com>
CC: n.brownlee@auckland.ac.nz, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix
 A
References: <BAY3-F32pY5GT9IeV3j00004303@hotmail.com>
In-Reply-To: <BAY3-F32pY5GT9IeV3j00004303@hotmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Jeff Meyer wrote:

> Nevil,
> 
>  My only contention would be that I did not do any direct data entry for 
> section 6.  I.e. I wrote the XML-Schema ran it through the publicly 
> available stylesheet and free transform engine and pasted it into the doc.
> 

Jeff that is your production process, but I understand the IETF
editors process it is more traditional. We only need a small error
in that process to produce a conflict between the two definitions.

>  Certainly it would be my hope that authors of additional information 
> models to be carried over IPFIX would follow the same process, because 
> then I can simply take their XML-Schema spec and use it in a variety of 
> tools.  If I only get text, then I have the tedious prospect of 
> transcribing it.  If equipment providers favor a manual transcription 
> process, it is certainly not precluded.
> 
>  My understanding was that PSAMP might be using the XML technique today, 
> I believe it was Juergen who asked about the tools and I passed along 
> the pointer.
> 
>  If it is politically simpler to call section 6 normative but indicate 
> that authors of new models SHOULD create an XML-Schema model and MAY 
> machine translate these models to create the normative text, then I 
> could live with such a compromise.
> 
>  Simply excising this information as Stewart seems to be advocating 
> seems like a step backwards and I'm at a loss to see any benefit from that.
>

You will get a reduction in size of the main text, and the ability to
make the XML track any errors which is not possible in a single document
without issuing a new RFC number.

Regards

Stewart

> Regards,
> 
>  Jeff Meyer
> 
> 
>> From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
>> To: Jeff Meyer <inetpix@msn.com>
>> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 
>> vs.Appendix A
>> Date: Thu, 29 Jan 2004 13:02:07 +1300
>>
>> Stewart and Jeff:
>>
>> >   With the use of XSL stylesheets the XML style informaiton model 
>> could be
>> > transformed automatically into any set of text one would want, e.g. IOS
>> > commands to enable flags, HTML tables for presentation, RFC2629 
>> entries in
>> > an RFC document, etc.  For a discussion and example of using free 
>> XSL tools
>> > to process this you can see
>> > http://www.ipdr.org/documents/ipfix/infomodel/README.html.
>>
>> Jeff's right in saying that XML is becoming more widely used within the
>> IETF, as evidenced by RFC 2629 and the fact that more WGs (espcially
>> in the Applications Area) are using it.
>>
>> However, RFC 2629 explicitly says it doesn't address "IETF politics"
>> issues.  My take on that is that the text in section 6 of the Info Model
>> draft is the normative version; Appendix A gives the xml because people
>> may find it useful, but if they use it they should check that it really
>> does match the (normative) text version.
>>
>> As for IPFIX WG consensus on this, in my view the document editors
>> are free to use whatever tools they need to produce the actual drafts.
>> Furthermore, including the xml as an appendix allows other people to
>> use the xml for other purposes, which (I guess) is why the editors
>> appended it to the draft.
>>
>> Does that make the situation clearer?
>>
>> -----------------------------------------------------------------------
>>    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:majordomo@net.doit.wisc.edu and say "help" in 
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 
> _________________________________________________________________
> Learn how to choose, serve, and enjoy wine at Wine @ MSN. 
> http://wine.msn.com/
> 
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 06:22:27 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12980
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 06:22:27 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Am9vR-0005aM-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 05:01:33 -0600
Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Am9vQ-0005aF-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 05:01:33 -0600
Received: from india-core-1.cisco.com (64.104.129.221)
  by ind-iport-1.cisco.com with ESMTP; 29 Jan 2004 22:01:46 +0530
Received: from cisco.com (edinburgh.cisco.com [144.254.112.76])
	by india-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0TB1Ius000040;
	Thu, 29 Jan 2004 03:01:20 -0800 (PST)
Received: from gtaylor-w2kl.cisco.com (edin-comm-vl10-dhcp18.cisco.com [144.254.112.38])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA20931;
	Thu, 29 Jan 2004 11:01:19 GMT
Message-Id: <6.0.0.22.2.20040129105302.02a72958@edinburgh.cisco.com>
X-Sender: gtaylor@edinburgh.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Thu, 29 Jan 2004 10:59:28 +0000
To: plonka@doit.wisc.edu
From: George M Taylor <gtaylor@cisco.com>
Subject: Re: [ipfix] IPFIX status, propose not meeting at 59th IETF
  (Seoul)
Cc: ipfix@net.doit.wisc.edu
In-Reply-To: <20040108161700.A13837@doit.wisc.edu>
References: <20040108161700.A13837@doit.wisc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Hi,

 From this email I've been assuming that there will be no meeting in Korea 
for IPFIX and related areas.

However after talking to someone yesterday it would appear to be necessary 
for a meeting in March.
I won't go into details, since I heard only 2nd hand that there is a lot of 
work to be covered.
I'll leave that to other list members to raise.

Given the cut off for Hotel bookings on Feb 1st and the increase in flight 
costs as we get closer to March can we have a final decision please 
sometime soon?

Thanks,
George


At 22:17 08/01/2004, Dave Plonka wrote:
>IPFIXers,
>
>Please review the status update (thanks to Nevil) below and
>this proposal from Nevil and I:
>
>At this stage there don't appear to be any 'show-stopper' issues, which
>raises the question, "Do we need to hold an IPFIX meeting in Seoul?"
>
>Your WG co-chairs feel that what's needed is concentrated work to
>finish the four IPFIX drafts so that the protocol can be implemented
>from the definition.  It would be great to get the drafts to WG last
>call by late February and finished by the end of March.
>
>How do WG members feel about this proposal?
>
>If we were to meet in Seoul, what are the main issues we'd need to
>discuss?  It would be quite a challenge for either of us to attend in
>Seoul, so any such issues would have to be compelling.
>
>Cheers,
>Dave & Nevil
>
>--
>
>    IPFIX WG: Status as of 9 Jan 04
>    -------------------------------
>
>    1. WG Drafts being considered by IESG
>
>       - Requirements Draft, version 13
>       - Evaluation draft:
>         Simon is revising following comments from Bert (Ops AD)
>
>    2. Milestones
>
>       Have been reivsed as discussed at Minneapolis meeting.  Looking
>       at them on the IPFIX charter page, I see that I've left out the
>       PROTOCOL draft - that goes along with the ARCHITECTURE,
>       INFO_MODEL and APPLICABILITY drafts.
>
>       Those four drafts have a milestone date saying they'll be
>       submitted to IESG by May 04.  Note that we set that date assuming
>       that they'd all be in their final stages by the next meeting
>       (Seoul, 29 Feb - 5 Mar 04).  Since other WGs (e.g. PSAMP) are
>       waiting for them, we would be good to get them done before that!
>
>    3. Current drafts
>
>       These are the four referred to in capitals above.  There's been
>       quite a lot of mailing-list discussion of various issues relating
>       to PROTOCOL and INFO_MODEL in the last month or so, which is
>       great.  Also, that discussion has been fairly well-structured,
>       i.e. we've managed to keep the issues separate by using their
>       issue number in the subject lines.
>
>--
>plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 06:54:18 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14006
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 06:54:18 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmAQ5-0006tA-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 05:33:13 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmAQ4-0006t4-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 05:33:12 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0TBX5NG087662
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 12:33:10 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0TBUmMN087428
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 12:30:48 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0TBUlN8087416; Thu, 29 Jan 2004 12:30:48 +0100 (CET)
Received: from [10.1.1.171] (n-quittek.office [10.1.1.171])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 31AEEDFF6D; Thu, 29 Jan 2004 12:30:45 +0100 (CET)
Date: Thu, 29 Jan 2004 12:30:58 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Jeff Meyer <inetpix@msn.com>, n.brownlee@auckland.ac.nz
Cc: stbryant@cisco.com, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A
Message-ID: <2147483647.1075379458@[10.1.1.171]>
In-Reply-To: <BAY3-F32pY5GT9IeV3j00004303@hotmail.com>
References:  <BAY3-F32pY5GT9IeV3j00004303@hotmail.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Jeff,

We had this entire discussion already some time ago.

For me, the main argument is that all IETF standards so far
are human-readable.  The XML document in the Appendix is hardly
readable, while section 6 is well readable.

You are requesting to move from a human-readable standard
to a machine-readable standard.  I understand that there are
several good reasons to do so.  But the change in the
standardization approach is fundamental.

This might be an issue for the ietf@ieft mailing list.
However, so far very few protocols or models in the IETF
have been formally defined. Looks like still the 'running
code' approach dominates the 'well specified' approach.

Regards,

     Juergen

--On 28.01.2004 19:53 h -0800 Jeff Meyer wrote:

> Nevil,
>
>   My only contention would be that I did not do any direct data entry for section 6.  I.e. I wrote the XML-Schema ran it through the publicly available stylesheet and free transform engine and pasted it into the doc.
>
>   Certainly it would be my hope that authors of additional information models to be carried over IPFIX would follow the same process, because then I can simply take their XML-Schema spec and use it in a variety of tools.  If I only get text, then I
> have the tedious prospect of transcribing it.  If equipment providers favor a manual transcription process, it is certainly not precluded.
>
>   My understanding was that PSAMP might be using the XML technique today, I believe it was Juergen who asked about the tools and I passed along the pointer.
>
>   If it is politically simpler to call section 6 normative but indicate that authors of new models SHOULD create an XML-Schema model and MAY machine translate these models to create the normative text, then I could live with such a compromise.
>
>   Simply excising this information as Stewart seems to be advocating seems like a step backwards and I'm at a loss to see any benefit from that.
>
> Regards,
>
>   Jeff Meyer
>
>
>> From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
>> To: Jeff Meyer <inetpix@msn.com>
>> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6
>> vs.Appendix A
>> Date: Thu, 29 Jan 2004 13:02:07 +1300
>>
>> Stewart and Jeff:
>>
>> >   With the use of XSL stylesheets the XML style informaiton model could
>> be
>> > transformed automatically into any set of text one would want, e.g. IOS
>> > commands to enable flags, HTML tables for presentation, RFC2629 entries
>> in
>> > an RFC document, etc.  For a discussion and example of using free XSL
>> tools
>> > to process this you can see
>> > http://www.ipdr.org/documents/ipfix/infomodel/README.html.
>>
>> Jeff's right in saying that XML is becoming more widely used within the
>> IETF, as evidenced by RFC 2629 and the fact that more WGs (espcially
>> in the Applications Area) are using it.
>>
>> However, RFC 2629 explicitly says it doesn't address "IETF politics"
>> issues.  My take on that is that the text in section 6 of the Info Model
>> draft is the normative version; Appendix A gives the xml because people
>> may find it useful, but if they use it they should check that it really
>> does match the (normative) text version.
>>
>> As for IPFIX WG consensus on this, in my view the document editors
>> are free to use whatever tools they need to produce the actual drafts.
>> Furthermore, including the xml as an appendix allows other people to
>> use the xml for other purposes, which (I guess) is why the editors
>> appended it to the draft.
>>
>> Does that make the situation clearer?
>>
>> -----------------------------------------------------------------------
>>    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:majordomo@net.doit.wisc.edu and say "help" in message
>> body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>
> _________________________________________________________________
> Learn how to choose, serve, and enjoy wine at Wine @ MSN. http://wine.msn.com/
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 07:08:46 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14309
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 07:08:45 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmAnu-0007eJ-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 05:57:50 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmAnt-0007eE-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 05:57:49 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0TBvkNA090423
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 12:57:47 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0TBvj0B090419
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 12:57:45 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0TBvjN8090417; Thu, 29 Jan 2004 12:57:45 +0100 (CET)
Received: from [10.1.1.171] (n-quittek.office [10.1.1.171])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id C920CFA8B2; Thu, 29 Jan 2004 12:57:43 +0100 (CET)
Date: Thu, 29 Jan 2004 12:57:57 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-27  Information model reconciliation with NetflowV9 Draft
Message-ID: <2147483647.1075381077@[10.1.1.171]>
In-Reply-To: <BAY3-F39op69TeCDXRT00009a6f@hotmail.com>
References:  <BAY3-F39op69TeCDXRT00009a6f@hotmail.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Jeff,

The open problem I see here is fixing
the set of information elements
that are part of the IPFIX INFO model.
We are free to choose this set except that
we should avoid conficting numbers between
NFv9 and IPFIX.

Regards,

    Juergen

--On 26.01.2004 23:51 Uhr -0800 Jeff Meyer wrote:

> There are a large number of information elements defined in the NFv9 draft in
> section 8 "Field Type Definitions" which are not currently part of the IPFIX information
> model.
>
> There are a smaller set of information elements currently defined in ipfix-info which
> are not defined in NFv9.
>
> Note all common IE's are defined to have the same fieldId value.
>
> A summary of the deltas between the two documents is available at:
>
>   http://inetpix.com/ipfix/NFv9_IPFIX_info_comparison.xls
>
> It would appear that some of the information elements defined in NFv9 are actually
> option data vs. flow data (see issue INFO-26 at http://ipfix.doit.wisc.edu/archive/2360.html).
>
> Proposal would be to take a subset of these information elements from NFv9 into ipfix.
>
> The value of the current ipfix-info elements which fall outside of NFv9 is also worth
> questioning.
>
> -- Jeff Meyer
>
> _________________________________________________________________
> Let the new MSN Premium Internet Software make the most of your high-speed experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 07:10:40 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14360
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 07:10:40 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmAa5-0007FK-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 05:43:33 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmAa4-0007FF-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 05:43:32 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0TBhPNK088814
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 12:43:31 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0TBfoI0088540
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 12:41:50 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0TBfoN8088538; Thu, 29 Jan 2004 12:41:50 +0100 (CET)
Received: from [10.1.1.171] (n-quittek.office [10.1.1.171])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 19265F7048; Thu, 29 Jan 2004 12:41:48 +0100 (CET)
Date: Thu, 29 Jan 2004 12:42:01 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: stbryant@cisco.com, Jeff Meyer <inetpix@msn.com>
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue]  INFO-26  Section 7 of info-02 should be reworded
Message-ID: <2147483647.1075380121@[10.1.1.171]>
In-Reply-To: <4016323F.9060808@cisco.com>
References: <BAY3-F36NTXiQD9Eg4400011d3d@hotmail.com> <4016323F.9060808@cisco.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

Stewart,

I completely agree.  Section 7 should be merged into the appendix,
because it explains why the appendix is there at all.  I do not
see a reason for seaprating Section 7 from the appendix.

    Juergen


--On 27.01.2004 9:41 Uhr +0000 Stewart Bryant wrote:

>
> Jeff Meyer wrote:
>> The current section 7 describes in general the benefits of an XML based
>> information model,
>> some would say too much.  It does not describe any specific applications
>> of this approach.
>>
>> Specifically the ability to serialize as either XML or binary documents,
>> collections of received
>> IPFIX flow records is a benefit.  This can be realized with existing
>> open source tools from
>> IPDR.  Elaborating on how this connection can be established would be
>> helpful to the
>> community, since persisting collected sets of flows is a common task in
>> today's netflow
>> deployments.
>>
>> -- Jeff Meyer
>>
>
> Jeff
>
> Section 7 contains no information necessary to implement the protocol
> and should be deleted.
>
> Assuming that we retain Appendix A, a synopsys of section 7 might be
> used in the introduction to that appendix, but I don't think that
> you really needs to say any more than "here is the definition
> in XML".
>
> If you think that an expanded version of section 7 is useful to
> the IETF community, then I think that should go in a seperate
> informational draft.
>
> BTW the current intro to Appendix A says:
>
> "The normative status of this appendix versus the section "Flow
> Attributes" is a point of discussion.  The "Flow Attributes" section
> is simply machine generated from the formal XML document below.  As
> such using the formal XML document would seem preferable.  However
> historical conventions and IETF's overall level of XML adoption may
> lead to selection of the human readable text in the "Flow Attributes"
> section as being preferable as normative."
>
> This needs to be replaced with a simple statement saying either:
>
> a) The text in the numeric sections of this draft/RFC is the
>     normative text,
>
> or
>
> b) The XML desctiption in this appendix is the normative text.
>
> thereby removing any ambigutity of the status of Appendix A.
>
> - Stewart
>
>
>
>
>
>
>
>
>> _________________________________________________________________
>> Find high-speed =91net deals ? comparison-shop your local providers here.
>> https://broadband.msn.com
>>
>>
>> --
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>> body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 07:11:06 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14384
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 07:11:04 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmAUz-0007CJ-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 05:38:17 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmAUy-0007CE-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 05:38:16 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0TBcENA088109
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 12:38:15 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0TBavlR088049
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 12:36:57 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0TBauN8088047; Thu, 29 Jan 2004 12:36:57 +0100 (CET)
Received: from [10.1.1.171] (n-quittek.office [10.1.1.171])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 8E05B131B7; Thu, 29 Jan 2004 12:36:55 +0100 (CET)
Date: Thu, 29 Jan 2004 12:37:09 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-25  Options data is not addressed in info-model
Message-ID: <2147483647.1075379829@[10.1.1.171]>
In-Reply-To: <BAY3-F36P4GHHU9ObBj00011d27@hotmail.com>
References:  <BAY3-F36P4GHHU9ObBj00011d27@hotmail.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Jeff,

I agree.  In the PSAMP INFO model <draft-ietf-psamp-info-00.txt>
there is already an additional entry in the list of properties of
en information elements to be specified for each element:

    Applicability - a statement in which flow records the attribute is
      used. An attribute can be exported in a data flow record, a
      options data flow record or both.

We should add this property also to the IPFIX INFO model to be stated
for each info element.

    Juergen


--On 26.01.2004 23:19 Uhr -0800 Jeff Meyer wrote:

> Currently the content of the information model deals with information elements related
> to a single flow (or possibly aggregated set of flows).
>
> There is another class of information which pertains to details about the exporter itself.
> (e.g. total number of flows exported, drops and other items).  Some of these are
> currently described in the protocol draft under the discussion of "Option Templates".
>
> These information elements should be described in the information model as well. Probably
> in a separate section dealing with "Exporter Detail Information".
>
> -- Jeff Meyer
>
> _________________________________________________________________
> Get a FREE online virus check for your PC here, from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 07:42:30 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15085
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 07:42:30 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmBKn-0000pF-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 06:31:49 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmBKl-0000p1-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 06:31:47 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0TCVgNA093846
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 13:31:43 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0TCV7Fc093824
	for <ipfix@net.doit.wisc.edu>; Thu, 29 Jan 2004 13:31:07 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0TCV6N8093821; Thu, 29 Jan 2004 13:31:07 +0100 (CET)
Received: from [10.1.1.171] (n-quittek.office [10.1.1.171])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 6928DDCE5E; Thu, 29 Jan 2004 13:31:05 +0100 (CET)
Date: Thu, 29 Jan 2004 13:31:19 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-29  Namespace definitions may need IANA considerations
Message-ID: <2147483647.1075383079@[10.1.1.171]>
In-Reply-To: <BAY3-F35Tzvb5YI9IJs0001e87a@hotmail.com>
References:  <BAY3-F35Tzvb5YI9IJs0001e87a@hotmail.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Jeff,

I suggest to follow a completely different way of solving this
problems such that everybody get what is needed.

I see the cause in our dispute that the Appendix of the INFO model
document is NOT just an information model, but a data model.

As you argued well some time ago, it is a bad idea specifying
binary encodings in the info model document, because this would
already be a data model, which may vary among different protocols
that potentially use the IPFIX INFO model.

So, it is completely correct, that the binary encoding has become
a part of the IPFIX PROTOCOL document.  But still the IPFIX INFO
model document contains a data model: the XML ASCII encoding for
each information element. This is a data model. IMHO this is wrong!

We should follow a clean approach by just specifying an
information model.  This would solve several of the open issues
we are discussing, including the name space problem (iprd:),
because we get completely independent of these data encoding issues
and still can support IPDR data types in XML-based applications.

Here is my suggestion:

Currently, the Appendix is an XML schema defining which fixes ASCII
encodings for each information element.  I suggest to replace this
XML schema by an XML document.  The document would consist of a set
of XML element, each of them specifying a single information elements
with a set of attributes and/or contained XML elements exactly
covering all properties of information elements as defined in section 3.
(We can use a small, simple XML schema for checking consistency of this
XML document.)

Information elements defined this way would not have a standard XML,
IPDR, or other data type (data model should be separated from info model),
but would be defined just by English text, for example
  ipfix-int: integer value in the range of -2147483648 to 2147483647
  ipfix-dateTime: number of seconds since Jan 1st, 1970, 00:00 h
  ipfix-ipv4address: integral representation of a 32 bit IPv4 address
  ...
We would create our own IPFIX type space for the information elements.

Based on this pure information model, we can use XSLT (as we do it now)
to generate all the text in Section 6 describing the information elements.

Now, if you want to realize an XML-based application, you can take the
new XML document and use XSLT for automatic generation of a schema, such
as the one we have in the Appendix of the current version of the INFO model
document.  You see, you still have all the advantages of the machine-
readability and all opportunities to generate IPFIX XML parsers automatically.
But with the suggested change you would also have a clean information model
in the IPFIX INFO document avoiding all discussions on whether or not to
use the IPDR data types.

I am currently working together with Thomas, editor of the PSAMP INFO
model, to implement the idea sketched above. We will send an example to
this list in a few days.

Regards,

    Juergen


--On 27.01.2004 23:55 h -0800 Jeff Meyer wrote:

> The current info-model-02 specification contains references to XML type names and semantics borrowed directly from the XML-Schema specification as well as extensions.
>
> Currently these extensions borrow from existing work of IPDR as well as newly identified types currently specific to IPFIX.
>
> There are a few ways to address this.
>
> The following e-mail thread discusses the options and opinion of this editor as well as opinions from Andrew Norton who is involved in IETF's and IANA's work in utilizing XML in RFC's.
>
>
> Jeff,
>
> It would seem that this is all a matter of "taste" as any of these options technically work.  Personally I would go with option 3; though it requires more coordination between organizations, to an outsider it would seem more cohesive.
>
> There is a practical difference between option 1 and option 3 in terms of setting the standard.  With option 3, if IPDR upgrades their standard, the IPFIX group needs to do nothing to incorporate the changes.  However, with option 1, IPFIX will have to
> standardize a new schema and issue new RFC's.
>
> -andy
>
> Jeff Meyer wrote:
>     Hi Andy,
>
> I wanted to get your opinion on extending the XML-Schema type system for some specific information modeling requirements encountered by the IPFIX working group.
>
> IPFIX currently reuses about 15 types from XML-Schema directly, however there are several types which are worthwile to distinguish from an IPFIX persepective which are not defined by XML-Schema.
>
> These include types to identify timestamps of specific resolution (e.g. mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and one for UUIDs.
>
> Today most of these extension types are defined in the public NDM-U 3.1.1 specification from the industry consortium called IPDR.org.  There are a couple which are not are related to the high resolution timestamps (uSec and nSec).
>
> The NDM-U 3.1.1 specificaiton is avaiable at http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically section A.4.4.
>
> The IPFIX-Info reference is available at:
>
> http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#anchor4
>
>
> This is a link to the specific secion in the HTML format of the info model based on RFC2629.
>
>
> The quesion at hand is whether to follow one of the following 3 options:
>
>    1. have a single XML-Schema which defines the extension types relevant to IPFIX and contained in the IPFIX namespace
>    2. reference the existing types targeted by IPDR and add only the new types specific to the IPFIX Schema
>    3. petition IPDR to define the remaining two IPFIX types for timestamps in their upcoming 3.5 specification (likely timeframe Feb. or March)
>
> I get the impression from IPFIX discussions that referencing IPDR is something that some vocal participants find objectionable, i.e. they would prefer to see option 1.
>
> My personal preference would be to go with option 3 or 2.  I believe 3 is doable and would reduce the number of places where people have to look for things.  Option 1 I see as creating some confusion in the space, but ultimately addressable through XSL
> or other mapping functions, if that's what it takes to get consensus.
>
>
> Any guidance on your part would be appreciated.
>
> Regards,
>
> Jeff Meyer
>
> _________________________________________________________________
> Get a FREE online virus check for your PC here, from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 13:41:26 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07227
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 13:41:26 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmGma-0003WA-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 12:20:52 -0600
Received: from bay3-f35.bay3.hotmail.com ([65.54.169.35] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmGmZ-0003W1-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 12:20:51 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 29 Jan 2004 10:20:49 -0800
Received: from 216.113.168.128 by by3fd.bay3.hotmail.msn.com with HTTP;
	Thu, 29 Jan 2004 18:20:49 GMT
X-Originating-IP: [216.113.168.128]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: quittek@ccrle.nec.de, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations
Date: Thu, 29 Jan 2004 10:20:49 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F35u23LiC1h1jY00023ba8@hotmail.com>
X-OriginalArrivalTime: 29 Jan 2004 18:20:49.0678 (UTC) FILETIME=[9F300AE0:01C3E694]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Juergen,

  XML-Schema can be thought of as a pure Informaiton Model.  XML-Schema and 
XML also define productions which can be used to create instance documents 
which are a data model and encoded in ASCII.  IPDR takes full advantage of 
this by providing both ASCII and Binary encodings from the same information 
model.  I.e. XML-Schema CAN be used AS IS as a pure information model.

  Think of ASN.1 which has a Syntax and various encoding rules such as BER, 
DER and others (even an XER).  At some point you need to formally define 
something, but that DOES NOT mean that the ASN.1 syntax is just a BINARY 
encoding model nor is it just one encoding model.  Hence it IS separate from 
encoding.

  I view XML-Schema as the ASN.1 of the 21st century, only with a much 
richer set of off the shelf and often free tools and other interoperable 
components.

  Renaming things which are well defined (e.g. int) to duplicate names (e.g. 
ipfix-int) is just a lot of unnecessary rework.  The temptation to simply 
redefine things is often large for engineers.  However in the long run 
reusing existing work increases the likelihood that people will converge on 
certain key patterns.

-- Jeff


>From: Juergen Quittek <quittek@ccrle.nec.de>
>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-29  Namespace definitions may need IANA 
>considerations
>Date: Thu, 29 Jan 2004 13:31:19 +0100
>
>Jeff,
>
>I suggest to follow a completely different way of solving this
>problems such that everybody get what is needed.
>
>I see the cause in our dispute that the Appendix of the INFO model
>document is NOT just an information model, but a data model.
>
>As you argued well some time ago, it is a bad idea specifying
>binary encodings in the info model document, because this would
>already be a data model, which may vary among different protocols
>that potentially use the IPFIX INFO model.
>
>So, it is completely correct, that the binary encoding has become
>a part of the IPFIX PROTOCOL document.  But still the IPFIX INFO
>model document contains a data model: the XML ASCII encoding for
>each information element. This is a data model. IMHO this is wrong!
>
>We should follow a clean approach by just specifying an
>information model.  This would solve several of the open issues
>we are discussing, including the name space problem (iprd:),
>because we get completely independent of these data encoding issues
>and still can support IPDR data types in XML-based applications.
>
>Here is my suggestion:
>
>Currently, the Appendix is an XML schema defining which fixes ASCII
>encodings for each information element.  I suggest to replace this
>XML schema by an XML document.  The document would consist of a set
>of XML element, each of them specifying a single information elements
>with a set of attributes and/or contained XML elements exactly
>covering all properties of information elements as defined in section 3.
>(We can use a small, simple XML schema for checking consistency of this
>XML document.)
>
>Information elements defined this way would not have a standard XML,
>IPDR, or other data type (data model should be separated from info model),
>but would be defined just by English text, for example
>  ipfix-int: integer value in the range of -2147483648 to 2147483647
>  ipfix-dateTime: number of seconds since Jan 1st, 1970, 00:00 h
>  ipfix-ipv4address: integral representation of a 32 bit IPv4 address
>  ...
>We would create our own IPFIX type space for the information elements.
>
>Based on this pure information model, we can use XSLT (as we do it now)
>to generate all the text in Section 6 describing the information elements.
>
>Now, if you want to realize an XML-based application, you can take the
>new XML document and use XSLT for automatic generation of a schema, such
>as the one we have in the Appendix of the current version of the INFO model
>document.  You see, you still have all the advantages of the machine-
>readability and all opportunities to generate IPFIX XML parsers 
>automatically.
>But with the suggested change you would also have a clean information model
>in the IPFIX INFO document avoiding all discussions on whether or not to
>use the IPDR data types.
>
>I am currently working together with Thomas, editor of the PSAMP INFO
>model, to implement the idea sketched above. We will send an example to
>this list in a few days.
>
>Regards,
>
>    Juergen
>
>
>--On 27.01.2004 23:55 h -0800 Jeff Meyer wrote:
>
>>The current info-model-02 specification contains references to XML type 
>>names and semantics borrowed directly from the XML-Schema specification as 
>>well as extensions.
>>
>>Currently these extensions borrow from existing work of IPDR as well as 
>>newly identified types currently specific to IPFIX.
>>
>>There are a few ways to address this.
>>
>>The following e-mail thread discusses the options and opinion of this 
>>editor as well as opinions from Andrew Norton who is involved in IETF's 
>>and IANA's work in utilizing XML in RFC's.
>>
>>
>>Jeff,
>>
>>It would seem that this is all a matter of "taste" as any of these options 
>>technically work.  Personally I would go with option 3; though it requires 
>>more coordination between organizations, to an outsider it would seem more 
>>cohesive.
>>
>>There is a practical difference between option 1 and option 3 in terms of 
>>setting the standard.  With option 3, if IPDR upgrades their standard, the 
>>IPFIX group needs to do nothing to incorporate the changes.  However, with 
>>option 1, IPFIX will have to
>>standardize a new schema and issue new RFC's.
>>
>>-andy
>>
>>Jeff Meyer wrote:
>>     Hi Andy,
>>
>>I wanted to get your opinion on extending the XML-Schema type system for 
>>some specific information modeling requirements encountered by the IPFIX 
>>working group.
>>
>>IPFIX currently reuses about 15 types from XML-Schema directly, however 
>>there are several types which are worthwile to distinguish from an IPFIX 
>>persepective which are not defined by XML-Schema.
>>
>>These include types to identify timestamps of specific resolution (e.g. 
>>mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and one for 
>>UUIDs.
>>
>>Today most of these extension types are defined in the public NDM-U 3.1.1 
>>specification from the industry consortium called IPDR.org.  There are a 
>>couple which are not are related to the high resolution timestamps (uSec 
>>and nSec).
>>
>>The NDM-U 3.1.1 specificaiton is avaiable at 
>>http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically section 
>>A.4.4.
>>
>>The IPFIX-Info reference is available at:
>>
>>http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#anchor4
>>
>>
>>This is a link to the specific secion in the HTML format of the info model 
>>based on RFC2629.
>>
>>
>>The quesion at hand is whether to follow one of the following 3 options:
>>
>>    1. have a single XML-Schema which defines the extension types relevant 
>>to IPFIX and contained in the IPFIX namespace
>>    2. reference the existing types targeted by IPDR and add only the new 
>>types specific to the IPFIX Schema
>>    3. petition IPDR to define the remaining two IPFIX types for 
>>timestamps in their upcoming 3.5 specification (likely timeframe Feb. or 
>>March)
>>
>>I get the impression from IPFIX discussions that referencing IPDR is 
>>something that some vocal participants find objectionable, i.e. they would 
>>prefer to see option 1.
>>
>>My personal preference would be to go with option 3 or 2.  I believe 3 is 
>>doable and would reduce the number of places where people have to look for 
>>things.  Option 1 I see as creating some confusion in the space, but 
>>ultimately addressable through XSL
>>or other mapping functions, if that's what it takes to get consensus.
>>
>>
>>Any guidance on your part would be appreciated.
>>
>>Regards,
>>
>>Jeff Meyer
>>
>>_________________________________________________________________
>>Get a FREE online virus check for your PC here, from McAfee. 
>>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
>

_________________________________________________________________
Find high-speed ‘net deals — comparison-shop your local providers here. 
https://broadband.msn.com


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 13:41:53 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07256
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 13:41:53 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmGdp-0003OG-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 12:11:49 -0600
Received: from bay3-f3.bay3.hotmail.com ([65.54.169.3] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmGdo-0003OA-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 12:11:49 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 29 Jan 2004 10:11:48 -0800
Received: from 216.113.168.128 by by3fd.bay3.hotmail.msn.com with HTTP;
	Thu, 29 Jan 2004 18:11:47 GMT
X-Originating-IP: [216.113.168.128]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: quittek@ccrle.nec.de, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-25 Options data is not addressed in info-model
Date: Thu, 29 Jan 2004 10:11:47 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F3Ohw2RlC6aVEp00003eef@hotmail.com>
X-OriginalArrivalTime: 29 Jan 2004 18:11:48.0039 (UTC) FILETIME=[5C587D70:01C3E693]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Juergen,

  I see two separate issues:

   1. Adding an applicability statement to the set of information captured 
for each attribute.  Sounds like a good idea to me.  (should be [issue] 
INFO-31)

   2. Segregating per flow information from exporter general information 
(i.e. Option Templates).

  I'd like to do both.

  I also notice in PSAMP that there is yet another field called "Usage", in 
scanning the text, it would appear to me that this typically is just a 
rewording of the "Description" and "Applicability" fields.  So I would 
question whether it is needed.

  Finally, I see there is text around XML in a section 7 in PSAMP, but no 
actual XML doc.  Did the group ever create an XML-Schema?  Or did they fill 
in the text based "template" from section 6?

-- Jeff


>From: Juergen Quittek <quittek@ccrle.nec.de>
>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-25  Options data is not addressed in 
>info-model
>Date: Thu, 29 Jan 2004 12:37:09 +0100
>
>Jeff,
>
>I agree.  In the PSAMP INFO model <draft-ietf-psamp-info-00.txt>
>there is already an additional entry in the list of properties of
>en information elements to be specified for each element:
>
>    Applicability - a statement in which flow records the attribute is
>      used. An attribute can be exported in a data flow record, a
>      options data flow record or both.
>
>We should add this property also to the IPFIX INFO model to be stated
>for each info element.
>
>    Juergen
>
>
>--On 26.01.2004 23:19 Uhr -0800 Jeff Meyer wrote:
>
>>Currently the content of the information model deals with information 
>>elements related
>>to a single flow (or possibly aggregated set of flows).
>>
>>There is another class of information which pertains to details about the 
>>exporter itself.
>>(e.g. total number of flows exported, drops and other items).  Some of 
>>these are
>>currently described in the protocol draft under the discussion of "Option 
>>Templates".
>>
>>These information elements should be described in the information model as 
>>well. Probably
>>in a separate section dealing with "Exporter Detail Information".
>>
>>-- Jeff Meyer
>>
>>_________________________________________________________________
>>Get a FREE online virus check for your PC here, from McAfee. 
>>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
>
>
>--
>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>body
>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>"unsubscribe ipfix" in message body
>Archive     http://ipfix.doit.wisc.edu/archive/

_________________________________________________________________
Check out the new MSN 9 Dial-up — fast & reliable Internet access with prime 
features! http://join.msn.com/?pgmarket=en-us&page=dialup/home&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 13:43:12 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07282
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 13:43:12 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmGkg-0003UW-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 12:18:54 -0600
Received: from mailhub2.lawrence.edu ([143.44.65.114] helo=lawrence.edu)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmGkg-0003UQ-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 12:18:54 -0600
Received: from [143.44.97.19] (HELO lawrence.edu)
  by lawrence.edu (CommuniGate Pro SMTP 4.1.8)
  with ESMTP id 3499665; Thu, 29 Jan 2004 12:18:53 -0600
Message-ID: <40194E8D.4030709@lawrence.edu>
Date: Thu, 29 Jan 2004 12:18:53 -0600
From: Robert Lowe <Robert.H.Lowe@lawrence.edu>
Organization: Lawrence University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
CC: Nevil Brownlee <n.brownlee@auckland.ac.nz>, carter@qosient.com,
        "'ipfix wg'" <ipfix@net.doit.wisc.edu>
Subject: Re: [ipfix] Forming consensus
References: <5C8959A16A71B449AE793CF52FBBED661AB46D@ptah.newyork.qosient.com> <1069006936.dd4e928c9b8ac@webmail.auckland.ac.nz> <3FBB8A0D.3030603@cisco.com>
In-Reply-To: <3FBB8A0D.3030603@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Benoit Claise wrote:

Benoit,

> Nevil and Carter,
> 
>>Hi Carter:
>>
>>  
>>
>>>   I think you need to point out which Cisco
>>>routers currently transport Netflow over SCTP.
>>>    
>>>
>>
>>You've raised a good point here, namely that the IETF works with rough
>>consensus and *running code*.  The thing about having *running code* is
>>that one is talking about a known quantity, not just speculation.
>>
> We are currenlty working on a SCTP-PR/NetFlow version 9 prototype.
> We're targetting the first week on January.

Not to uncover a bone of contention, but was there an update on this that
I missed?

-Robert


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 14:40:47 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11432
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 14:40:47 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmGUl-00032y-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 12:02:27 -0600
Received: from bay3-f41.bay3.hotmail.com ([65.54.169.41] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmGUk-00032s-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 12:02:26 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 29 Jan 2004 10:02:25 -0800
Received: from 216.113.168.128 by by3fd.bay3.hotmail.msn.com with HTTP;
	Thu, 29 Jan 2004 18:02:24 GMT
X-Originating-IP: [216.113.168.128]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: quittek@ccrle.nec.de, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-27 Information model reconciliation with NetflowV9
 Draft
Date: Thu, 29 Jan 2004 10:02:24 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F41fkSpdVyxX810000bea3@hotmail.com>
X-OriginalArrivalTime: 29 Jan 2004 18:02:25.0109 (UTC) FILETIME=[0CD03050:01C3E692]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Juergen,

  Yes, this was the problem I was trying to state.  In the Excel spreadsheet 
I've made some stab at what we may want to borrow.  I know long ago Paul 
Calato was planning to do some of this, but I don't think that happened.

  I'd be interested in hearing other proposals for things to borrow from 
NFv9 from others on the mailing list.

  I also question whether the four items which are in IPFIX but not NFv9 are 
appropriate:

  - nextHopAS  - NFv9 talks about IP addrs of next hop, but not AS numbers, 
are both useful?
  - ipV4SourceExporterAddress - seems useful, is there a reason NFv9 didn't 
declare it?
  - ipV6SourceExporterAddress - seems useful, is there a reason NFv9 didn't 
declare it?
  - droppedPacketCount - seems useful, is there a reason NFv9 didn't declare 
it?

-- Jeff

>From: Juergen Quittek <quittek@ccrle.nec.de>
>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-27  Information model reconciliation with 
>NetflowV9 Draft
>Date: Thu, 29 Jan 2004 12:57:57 +0100
>
>Jeff,
>
>The open problem I see here is fixing
>the set of information elements
>that are part of the IPFIX INFO model.
>We are free to choose this set except that
>we should avoid conficting numbers between
>NFv9 and IPFIX.
>
>Regards,
>
>    Juergen
>
>--On 26.01.2004 23:51 Uhr -0800 Jeff Meyer wrote:
>
>>There are a large number of information elements defined in the NFv9 draft 
>>in
>>section 8 "Field Type Definitions" which are not currently part of the 
>>IPFIX information
>>model.
>>
>>There are a smaller set of information elements currently defined in 
>>ipfix-info which
>>are not defined in NFv9.
>>
>>Note all common IE's are defined to have the same fieldId value.
>>
>>A summary of the deltas between the two documents is available at:
>>
>>   http://inetpix.com/ipfix/NFv9_IPFIX_info_comparison.xls
>>
>>It would appear that some of the information elements defined in NFv9 are 
>>actually
>>option data vs. flow data (see issue INFO-26 at 
>>http://ipfix.doit.wisc.edu/archive/2360.html).
>>
>>Proposal would be to take a subset of these information elements from NFv9 
>>into ipfix.
>>
>>The value of the current ipfix-info elements which fall outside of NFv9 is 
>>also worth
>>questioning.
>>
>>-- Jeff Meyer
>>
>>_________________________________________________________________
>>Let the new MSN Premium Internet Software make the most of your high-speed 
>>experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
>

_________________________________________________________________
Let the new MSN Premium Internet Software make the most of your high-speed 
experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 14:45:37 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11771
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 14:45:36 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmGGc-0002YM-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 11:47:50 -0600
Received: from bay3-f5.bay3.hotmail.com ([65.54.169.5] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmGGc-0002YE-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 11:47:50 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 29 Jan 2004 09:47:45 -0800
Received: from 216.113.168.128 by by3fd.bay3.hotmail.msn.com with HTTP;
	Thu, 29 Jan 2004 17:47:44 GMT
X-Originating-IP: [216.113.168.128]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz
Cc: stbryant@cisco.com, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A
Date: Thu, 29 Jan 2004 09:47:44 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F52SjI2qrZNTXi000123c5@hotmail.com>
X-OriginalArrivalTime: 29 Jan 2004 17:47:45.0000 (UTC) FILETIME=[003A3680:01C3E690]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Juergen,

  I agree few protocols have formal model specs.  SNMP, however, which has 
as a key value proposition the means of extensibility chose to define MIBs, 
quite formal. MIBs also suffer somewhat from difficulty in reading along 
with some other issues inherited from ASN.1 which are improved by XML.

  Since I believe one of the key aspects of IPFIX is the mechanism for 
extension, I think we should learn from another IETF protocol which seemed 
rather successful in addressing this requirement.

  So, I think maintaining the connection between the mechanism which is 
available today in IPFIX-info to formally specify the model is important, if 
there is an interest in drawing others to extend IPFIX with information 
content which differs from IPFIX's initial focus.

  One approach would be to break out another document as part of IPFIX, 
which would be something like  "Formal IPFIX Information Modeling".  But I'm 
not particularly eager to create another document.

-- Jeff


>From: Juergen Quittek <quittek@ccrle.nec.de>
>To: Jeff Meyer <inetpix@msn.com>, n.brownlee@auckland.ac.nz
>CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 
>vs.Appendix A
>Date: Thu, 29 Jan 2004 12:30:58 +0100
>
>Jeff,
>
>We had this entire discussion already some time ago.
>
>For me, the main argument is that all IETF standards so far
>are human-readable.  The XML document in the Appendix is hardly
>readable, while section 6 is well readable.
>
>You are requesting to move from a human-readable standard
>to a machine-readable standard.  I understand that there are
>several good reasons to do so.  But the change in the
>standardization approach is fundamental.
>
>This might be an issue for the ietf@ieft mailing list.
>However, so far very few protocols or models in the IETF
>have been formally defined. Looks like still the 'running
>code' approach dominates the 'well specified' approach.
>
>Regards,
>
>     Juergen
>
>--On 28.01.2004 19:53 h -0800 Jeff Meyer wrote:
>
>>Nevil,
>>
>>   My only contention would be that I did not do any direct data entry for 
>>section 6.  I.e. I wrote the XML-Schema ran it through the publicly 
>>available stylesheet and free transform engine and pasted it into the doc.
>>
>>   Certainly it would be my hope that authors of additional information 
>>models to be carried over IPFIX would follow the same process, because 
>>then I can simply take their XML-Schema spec and use it in a variety of 
>>tools.  If I only get text, then I
>>have the tedious prospect of transcribing it.  If equipment providers 
>>favor a manual transcription process, it is certainly not precluded.
>>
>>   My understanding was that PSAMP might be using the XML technique today, 
>>I believe it was Juergen who asked about the tools and I passed along the 
>>pointer.
>>
>>   If it is politically simpler to call section 6 normative but indicate 
>>that authors of new models SHOULD create an XML-Schema model and MAY 
>>machine translate these models to create the normative text, then I could 
>>live with such a compromise.
>>
>>   Simply excising this information as Stewart seems to be advocating 
>>seems like a step backwards and I'm at a loss to see any benefit from 
>>that.
>>
>>Regards,
>>
>>   Jeff Meyer
>>
>>
>>>From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
>>>To: Jeff Meyer <inetpix@msn.com>
>>>CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu
>>>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6
>>>vs.Appendix A
>>>Date: Thu, 29 Jan 2004 13:02:07 +1300
>>>
>>>Stewart and Jeff:
>>>
>>> >   With the use of XSL stylesheets the XML style informaiton model 
>>>could
>>>be
>>> > transformed automatically into any set of text one would want, e.g. 
>>>IOS
>>> > commands to enable flags, HTML tables for presentation, RFC2629 
>>>entries
>>>in
>>> > an RFC document, etc.  For a discussion and example of using free XSL
>>>tools
>>> > to process this you can see
>>> > http://www.ipdr.org/documents/ipfix/infomodel/README.html.
>>>
>>>Jeff's right in saying that XML is becoming more widely used within the
>>>IETF, as evidenced by RFC 2629 and the fact that more WGs (espcially
>>>in the Applications Area) are using it.
>>>
>>>However, RFC 2629 explicitly says it doesn't address "IETF politics"
>>>issues.  My take on that is that the text in section 6 of the Info Model
>>>draft is the normative version; Appendix A gives the xml because people
>>>may find it useful, but if they use it they should check that it really
>>>does match the (normative) text version.
>>>
>>>As for IPFIX WG consensus on this, in my view the document editors
>>>are free to use whatever tools they need to produce the actual drafts.
>>>Furthermore, including the xml as an appendix allows other people to
>>>use the xml for other purposes, which (I guess) is why the editors
>>>appended it to the draft.
>>>
>>>Does that make the situation clearer?
>>>
>>>-----------------------------------------------------------------------
>>>    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:majordomo@net.doit.wisc.edu and say "help" in message
>>>body
>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>"unsubscribe ipfix" in message body
>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>_________________________________________________________________
>>Learn how to choose, serve, and enjoy wine at Wine @ MSN. 
>>http://wine.msn.com/
>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
>

_________________________________________________________________
There are now three new levels of MSN Hotmail Extra Storage!  Learn more. 
http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 18:27:34 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29494
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 18:27:33 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmLLL-0005I9-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 17:13:03 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmLLK-0005Hy-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 17:13:03 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 30 Jan 2004 00:13:41 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i0TNCcCD029430;
	Fri, 30 Jan 2004 00:12:38 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp79.cisco.com [10.61.64.79])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA05480;
	Thu, 29 Jan 2004 23:12:52 GMT
Message-ID: <40199373.9060600@cisco.com>
Date: Thu, 29 Jan 2004 23:12:51 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeff Meyer <inetpix@msn.com>
CC: quittek@ccrle.nec.de, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-27 Information model reconciliation with
 NetflowV9 Draft
References: <BAY3-F41fkSpdVyxX810000bea3@hotmail.com>
In-Reply-To: <BAY3-F41fkSpdVyxX810000bea3@hotmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit



Jeff Meyer wrote:

> Juergen,
> 
>  Yes, this was the problem I was trying to state.  In the Excel 
> spreadsheet I've made some stab at what we may want to borrow.  I know 
> long ago Paul Calato was planning to do some of this, but I don't think 
> that happened.

I am working on reconsiling IPFIX and NFv9 and should have something
shortly.

> 
>  I'd be interested in hearing other proposals for things to borrow from 
> NFv9 from others on the mailing list.
> 

Working on it.

>  I also question whether the four items which are in IPFIX but not NFv9 
> are appropriate:
> 
>  - nextHopAS  - NFv9 talks about IP addrs of next hop, but not AS 
> numbers, are both useful?

You need to know the AS for peering charges, saves the collector having
to figure it out by merging BGP next hop and the output from IBGP.

>  - ipV4SourceExporterAddress - seems useful, is there a reason NFv9 
> didn't declare it?

NFv9 did not really consider proxies which I think need this.

>  - ipV6SourceExporterAddress - seems useful, is there a reason NFv9 
> didn't declare it?

As above

>  - droppedPacketCount - seems useful, is there a reason NFv9 didn't 
> declare it?

I don't think that this is available to Netflow. For example if RED dropped
the packet, it does not have the ability to call back into Netflow to report it.
Same for any multi-linecard drop.

It is simple to declare it, but I would not expect that it would be
found on many of the high end platforms due to implementation constraints.

- Stewart

> 
> -- Jeff
> 
>> From: Juergen Quittek <quittek@ccrle.nec.de>
>> To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] [issue] INFO-27  Information model reconciliation 
>> with NetflowV9 Draft
>> Date: Thu, 29 Jan 2004 12:57:57 +0100
>>
>> Jeff,
>>
>> The open problem I see here is fixing
>> the set of information elements
>> that are part of the IPFIX INFO model.
>> We are free to choose this set except that
>> we should avoid conficting numbers between
>> NFv9 and IPFIX.
>>
>> Regards,
>>
>>    Juergen
>>
>> --On 26.01.2004 23:51 Uhr -0800 Jeff Meyer wrote:
>>
>>> There are a large number of information elements defined in the NFv9 
>>> draft in
>>> section 8 "Field Type Definitions" which are not currently part of 
>>> the IPFIX information
>>> model.
>>>
>>> There are a smaller set of information elements currently defined in 
>>> ipfix-info which
>>> are not defined in NFv9.
>>>
>>> Note all common IE's are defined to have the same fieldId value.
>>>
>>> A summary of the deltas between the two documents is available at:
>>>
>>>   http://inetpix.com/ipfix/NFv9_IPFIX_info_comparison.xls
>>>
>>> It would appear that some of the information elements defined in NFv9 
>>> are actually
>>> option data vs. flow data (see issue INFO-26 at 
>>> http://ipfix.doit.wisc.edu/archive/2360.html).
>>>
>>> Proposal would be to take a subset of these information elements from 
>>> NFv9 into ipfix.
>>>
>>> The value of the current ipfix-info elements which fall outside of 
>>> NFv9 is also worth
>>> questioning.
>>>
>>> -- Jeff Meyer
>>>
>>> _________________________________________________________________
>>> Let the new MSN Premium Internet Software make the most of your 
>>> high-speed experience. 
>>> http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
>>>
>>>
>>> -- 
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>> message body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>>
>>
>>
> 
> _________________________________________________________________
> Let the new MSN Premium Internet Software make the most of your 
> high-speed experience. 
> http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
> 
> 
> -- 
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Thu Jan 29 23:45:35 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11557
	for <ipfix-archive@lists.ietf.org>; Thu, 29 Jan 2004 23:45:34 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmQ55-0006lx-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jan 2004 22:16:35 -0600
Received: from bay3-f22.bay3.hotmail.com ([65.54.169.22] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmQ54-0006ls-00
	for ipfix@net.doit.wisc.edu; Thu, 29 Jan 2004 22:16:34 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 29 Jan 2004 20:16:33 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Fri, 30 Jan 2004 04:16:33 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: stbryant@cisco.com
Cc: quittek@ccrle.nec.de, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-27 Information model reconciliation with NetflowV9
 Draft
Date: Thu, 29 Jan 2004 20:16:33 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F22ilzDhBlt79E0002d75d@hotmail.com>
X-OriginalArrivalTime: 30 Jan 2004 04:16:33.0745 (UTC) FILETIME=[D84FD410:01C3E6E7]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

OK,

  Thanks Stewart, looking forward to your response.  Sounds like you're in 
favor of keeping the existing items which are in IPFIX, but fall outside of 
NFv9, which is fine by me.

-- Jeff


>From: Stewart Bryant <stbryant@cisco.com>
>Reply-To: stbryant@cisco.com
>To: Jeff Meyer <inetpix@msn.com>
>CC: quittek@ccrle.nec.de, ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-27 Information model reconciliation with 
>NetflowV9 Draft
>Date: Thu, 29 Jan 2004 23:12:51 +0000
>
>
>
>Jeff Meyer wrote:
>
>>Juergen,
>>
>>  Yes, this was the problem I was trying to state.  In the Excel 
>>spreadsheet I've made some stab at what we may want to borrow.  I know 
>>long ago Paul Calato was planning to do some of this, but I don't think 
>>that happened.
>
>I am working on reconsiling IPFIX and NFv9 and should have something
>shortly.
>
>>
>>  I'd be interested in hearing other proposals for things to borrow from 
>>NFv9 from others on the mailing list.
>>
>
>Working on it.
>
>>  I also question whether the four items which are in IPFIX but not NFv9 
>>are appropriate:
>>
>>  - nextHopAS  - NFv9 talks about IP addrs of next hop, but not AS 
>>numbers, are both useful?
>
>You need to know the AS for peering charges, saves the collector having
>to figure it out by merging BGP next hop and the output from IBGP.
>
>>  - ipV4SourceExporterAddress - seems useful, is there a reason NFv9 
>>didn't declare it?
>
>NFv9 did not really consider proxies which I think need this.
>
>>  - ipV6SourceExporterAddress - seems useful, is there a reason NFv9 
>>didn't declare it?
>
>As above
>
>>  - droppedPacketCount - seems useful, is there a reason NFv9 didn't 
>>declare it?
>
>I don't think that this is available to Netflow. For example if RED dropped
>the packet, it does not have the ability to call back into Netflow to 
>report it.
>Same for any multi-linecard drop.
>
>It is simple to declare it, but I would not expect that it would be
>found on many of the high end platforms due to implementation constraints.
>
>- Stewart
>
>>
>>-- Jeff
>>
>>>From: Juergen Quittek <quittek@ccrle.nec.de>
>>>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>>>Subject: Re: [ipfix] [issue] INFO-27  Information model reconciliation 
>>>with NetflowV9 Draft
>>>Date: Thu, 29 Jan 2004 12:57:57 +0100
>>>
>>>Jeff,
>>>
>>>The open problem I see here is fixing
>>>the set of information elements
>>>that are part of the IPFIX INFO model.
>>>We are free to choose this set except that
>>>we should avoid conficting numbers between
>>>NFv9 and IPFIX.
>>>
>>>Regards,
>>>
>>>    Juergen
>>>
>>>--On 26.01.2004 23:51 Uhr -0800 Jeff Meyer wrote:
>>>
>>>>There are a large number of information elements defined in the NFv9 
>>>>draft in
>>>>section 8 "Field Type Definitions" which are not currently part of the 
>>>>IPFIX information
>>>>model.
>>>>
>>>>There are a smaller set of information elements currently defined in 
>>>>ipfix-info which
>>>>are not defined in NFv9.
>>>>
>>>>Note all common IE's are defined to have the same fieldId value.
>>>>
>>>>A summary of the deltas between the two documents is available at:
>>>>
>>>>   http://inetpix.com/ipfix/NFv9_IPFIX_info_comparison.xls
>>>>
>>>>It would appear that some of the information elements defined in NFv9 
>>>>are actually
>>>>option data vs. flow data (see issue INFO-26 at 
>>>>http://ipfix.doit.wisc.edu/archive/2360.html).
>>>>
>>>>Proposal would be to take a subset of these information elements from 
>>>>NFv9 into ipfix.
>>>>
>>>>The value of the current ipfix-info elements which fall outside of NFv9 
>>>>is also worth
>>>>questioning.
>>>>
>>>>-- Jeff Meyer
>>>>
>>>>_________________________________________________________________
>>>>Let the new MSN Premium Internet Software make the most of your 
>>>>high-speed experience. 
>>>>http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
>>>>
>>>>
>>>>--
>>>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>>>>body
>>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>"unsubscribe ipfix" in message body
>>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>>
>>>
>>>
>>
>>_________________________________________________________________
>>Let the new MSN Premium Internet Software make the most of your high-speed 
>>experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>

_________________________________________________________________
Check out the coupons and bargains on MSN Offers! 
http://shopping.msn.com/softcontent/softcontent.aspx?scmId=1418


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 30 08:16:34 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14516
	for <ipfix-archive@lists.ietf.org>; Fri, 30 Jan 2004 08:16:34 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmYEk-0001Vo-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jan 2004 06:59:06 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmYEj-0001Vi-00
	for ipfix@net.doit.wisc.edu; Fri, 30 Jan 2004 06:59:05 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0UCx1NA080924
	for <ipfix@net.doit.wisc.edu>; Fri, 30 Jan 2004 13:59:03 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0UCwvs7080915
	for <ipfix@net.doit.wisc.edu>; Fri, 30 Jan 2004 13:58:57 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0UCwuN8080907; Fri, 30 Jan 2004 13:58:57 +0100 (CET)
Received: from [10.1.1.171] (n-quittek.office [10.1.1.171])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 19CB9C8579; Fri, 30 Jan 2004 13:58:55 +0100 (CET)
Date: Fri, 30 Jan 2004 13:59:10 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations
Message-ID: <2147483647.1075471150@[10.1.1.171]>
In-Reply-To: <BAY3-F35u23LiC1h1jY00023ba8@hotmail.com>
References:  <BAY3-F35u23LiC1h1jY00023ba8@hotmail.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

Jeff,

--On 29.01.2004 10:20 Uhr -0800 Jeff Meyer wrote:

> Juergen,
>
>   XML-Schema can be thought of as a pure Informaiton Model.

Of course we can say:
  "Here is a combined info and data model, please ignore the data model part,
   because this standard is just about the info model."

But this appears to be - at least - curious.

> XML-Schema and XML also define productions which can be used to create
> instance documents which are a data model and encoded in ASCII.

This is what people call a data model.

> IPDR takes full advantage of this by providing both
> ASCII and Binary encodings from the same information model.
> I.e. XML-Schema CAN be used AS IS as a pure information model.

Yes and we can have exactly the same with what I suggested.
The current version of the IPFIX INFO model does not contain
a binary encoding, but it does contain an ASCII encoding.

>   Think of ASN.1 which has a Syntax and various encoding rules such
> as BER, DER and others (even an XER).  At some point you need to
> formally define something, but that DOES NOT mean that the ASN.1
> syntax is just a BINARY encoding model nor is it just
> one encoding model.  Hence it IS separate from encoding.
>
>   I view XML-Schema as the ASN.1 of the 21st century, only with a
> much richer set of off the shelf and often free tools and other
> interoperable components.

I am sure you do not claim to inherit all properties of ASN.1 ;-)

>   Renaming things which are well defined (e.g. int) to duplicate
> names (e.g. ipfix-int) is just a lot of unnecessary rework.
> The temptation to simply redefine things is often large for
> engineers.  However in the long run reusing existing work
> increases the likelihood that people will converge on certain
> key patterns.

It is not just renaming.  It is replacing the concrete XML data type
with an abstract one that can be mapped to XML as well as to many other
domains.  And if you look at other INFO models, for example defined
in CIM by the DMTF, always abstract data types are used in info models.
Concrete ones are just used in data models.

But even if you just consider it as renaming, it solves some problems.
  [And having worked as software engineer, I know that renaming (e.g. by
   endless sets of #DEFINEs in C and C++ is not really unusual.]
The problems we can solve are

  1. We can replace 'hexBinary' by 'octetArray' or something else.
     Why should a binary data type use 'hex' in its name, if not ONLY
     with respect to its ASCII data encoding?  And the encoding that really
     is of importance for IPFIX standardization is the binary encoding
     by the protocol.

  2. We do not have to refer to an IPDR document as a normative reference.
     This has three implications:

     First, I do not know if this is (so far) possible at all for IETF
     standard track documents.

     Second, I am not sure if the IPDR definition of IPv4 addresses and IPv6
     addresses is what the IETF would like to use.  It does not make sense
     to import IPv4 address XML encoding from the IPDR definitions in one
     IETF standard and to use another source in another IETF standard.

     Third, if we use our own ABSTRACT data types, users can more easily
     choose other XML encodings than the one promoted by IPDR.
     [Nothing against IPDR. I like it very much and my company is a member]
     Management systems and database builders/integrators may/will already
     have their own (XML) data types for flow recording. If we use an
     abstract data type we do not explicitly request them to use the
     IPDR definitions.


    Juergen

> -- Jeff
>
>
>> From: Juergen Quittek <quittek@ccrle.nec.de>
>> To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] [issue] INFO-29  Namespace definitions may need IANA
>> considerations
>> Date: Thu, 29 Jan 2004 13:31:19 +0100
>>
>> Jeff,
>>
>> I suggest to follow a completely different way of solving this
>> problems such that everybody get what is needed.
>>
>> I see the cause in our dispute that the Appendix of the INFO model
>> document is NOT just an information model, but a data model.
>>
>> As you argued well some time ago, it is a bad idea specifying
>> binary encodings in the info model document, because this would
>> already be a data model, which may vary among different protocols
>> that potentially use the IPFIX INFO model.
>>
>> So, it is completely correct, that the binary encoding has become
>> a part of the IPFIX PROTOCOL document.  But still the IPFIX INFO
>> model document contains a data model: the XML ASCII encoding for
>> each information element. This is a data model. IMHO this is wrong!
>>
>> We should follow a clean approach by just specifying an
>> information model.  This would solve several of the open issues
>> we are discussing, including the name space problem (iprd:),
>> because we get completely independent of these data encoding issues
>> and still can support IPDR data types in XML-based applications.
>>
>> Here is my suggestion:
>>
>> Currently, the Appendix is an XML schema defining which fixes ASCII
>> encodings for each information element.  I suggest to replace this
>> XML schema by an XML document.  The document would consist of a set
>> of XML element, each of them specifying a single information elements
>> with a set of attributes and/or contained XML elements exactly
>> covering all properties of information elements as defined in section 3.
>> (We can use a small, simple XML schema for checking consistency of this
>> XML document.)
>>
>> Information elements defined this way would not have a standard XML,
>> IPDR, or other data type (data model should be separated from info model),
>> but would be defined just by English text, for example
>>  ipfix-int: integer value in the range of -2147483648 to 2147483647
>>  ipfix-dateTime: number of seconds since Jan 1st, 1970, 00:00 h
>>  ipfix-ipv4address: integral representation of a 32 bit IPv4 address
>>  ...
>> We would create our own IPFIX type space for the information elements.
>>
>> Based on this pure information model, we can use XSLT (as we do it now)
>> to generate all the text in Section 6 describing the information elements.
>>
>> Now, if you want to realize an XML-based application, you can take the
>> new XML document and use XSLT for automatic generation of a schema, such
>> as the one we have in the Appendix of the current version of the INFO model
>> document.  You see, you still have all the advantages of the machine-
>> readability and all opportunities to generate IPFIX XML parsers
>> automatically.
>> But with the suggested change you would also have a clean information model
>> in the IPFIX INFO document avoiding all discussions on whether or not to
>> use the IPDR data types.
>>
>> I am currently working together with Thomas, editor of the PSAMP INFO
>> model, to implement the idea sketched above. We will send an example to
>> this list in a few days.
>>
>> Regards,
>>
>>    Juergen
>>
>>
>> --On 27.01.2004 23:55 h -0800 Jeff Meyer wrote:
>>
>>> The current info-model-02 specification contains references to XML type
>>> names and semantics borrowed directly from the XML-Schema specification as
>>> well as extensions.
>>>
>>> Currently these extensions borrow from existing work of IPDR as well as
>>> newly identified types currently specific to IPFIX.
>>>
>>> There are a few ways to address this.
>>>
>>> The following e-mail thread discusses the options and opinion of this
>>> editor as well as opinions from Andrew Norton who is involved in IETF's
>>> and IANA's work in utilizing XML in RFC's.
>>>
>>>
>>> Jeff,
>>>
>>> It would seem that this is all a matter of "taste" as any of these options
>>> technically work.  Personally I would go with option 3; though it requires
>>> more coordination between organizations, to an outsider it would seem more
>>> cohesive.
>>>
>>> There is a practical difference between option 1 and option 3 in terms of
>>> setting the standard.  With option 3, if IPDR upgrades their standard, the
>>> IPFIX group needs to do nothing to incorporate the changes.  However, with
>>> option 1, IPFIX will have to
>>> standardize a new schema and issue new RFC's.
>>>
>>> -andy
>>>
>>> Jeff Meyer wrote:
>>>     Hi Andy,
>>>
>>> I wanted to get your opinion on extending the XML-Schema type system for
>>> some specific information modeling requirements encountered by the IPFIX
>>> working group.
>>>
>>> IPFIX currently reuses about 15 types from XML-Schema directly, however
>>> there are several types which are worthwile to distinguish from an IPFIX
>>> persepective which are not defined by XML-Schema.
>>>
>>> These include types to identify timestamps of specific resolution (e.g.
>>> mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and one for
>>> UUIDs.
>>>
>>> Today most of these extension types are defined in the public NDM-U 3.1.1
>>> specification from the industry consortium called IPDR.org.  There are a
>>> couple which are not are related to the high resolution timestamps (uSec
>>> and nSec).
>>>
>>> The NDM-U 3.1.1 specificaiton is avaiable at
>>> http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically section
>>> A.4.4.
>>>
>>> The IPFIX-Info reference is available at:
>>>
>>> http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#anchor4
>>>
>>>
>>> This is a link to the specific secion in the HTML format of the info model
>>> based on RFC2629.
>>>
>>>
>>> The quesion at hand is whether to follow one of the following 3 options:
>>>
>>>    1. have a single XML-Schema which defines the extension types relevant
>>> to IPFIX and contained in the IPFIX namespace
>>>    2. reference the existing types targeted by IPDR and add only the new
>>> types specific to the IPFIX Schema
>>>    3. petition IPDR to define the remaining two IPFIX types for
>>> timestamps in their upcoming 3.5 specification (likely timeframe Feb. or
>>> March)
>>>
>>> I get the impression from IPFIX discussions that referencing IPDR is
>>> something that some vocal participants find objectionable, i.e. they would
>>> prefer to see option 1.
>>>
>>> My personal preference would be to go with option 3 or 2.  I believe 3 is
>>> doable and would reduce the number of places where people have to look for
>>> things.  Option 1 I see as creating some confusion in the space, but
>>> ultimately addressable through XSL
>>> or other mapping functions, if that's what it takes to get consensus.
>>>
>>>
>>> Any guidance on your part would be appreciated.
>>>
>>> Regards,
>>>
>>> Jeff Meyer
>>>
>>> _________________________________________________________________
>>> Get a FREE online virus check for your PC here, from McAfee.
>>> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963
>>>
>>>
>>> --
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>> body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>>
>>
>
> _________________________________________________________________
> Find high-speed =91net deals ? comparison-shop your local providers here. https://broadband.msn.com
>





--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 30 09:44:48 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18915
	for <ipfix-archive@lists.ietf.org>; Fri, 30 Jan 2004 09:44:48 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmZ6Y-0003OU-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jan 2004 07:54:42 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmZ6X-0003OP-00
	for ipfix@net.doit.wisc.edu; Fri, 30 Jan 2004 07:54:41 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0UDsaNC090837
	for <ipfix@net.doit.wisc.edu>; Fri, 30 Jan 2004 14:54:39 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0UDrXvf090686
	for <ipfix@net.doit.wisc.edu>; Fri, 30 Jan 2004 14:53:33 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <Thomas.Dietz@netlab.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0UDrWN8090682; Fri, 30 Jan 2004 14:53:33 +0100 (CET)
Received: from [10.1.1.103] (dietz.office [10.1.1.103])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 842C8CAB9D; Fri, 30 Jan 2004 14:53:32 +0100 (CET)
Date: Fri, 30 Jan 2004 14:53:32 +0100
From: Thomas Dietz <Thomas.Dietz@netlab.nec.de>
To: Jeff Meyer <inetpix@msn.com>, quittek@ccrle.nec.de,
        ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-25 Options data is not addressed in
 info-model
Message-ID: <17360000.1075470812@dietz.office>
In-Reply-To: <BAY3-F3Ohw2RlC6aVEp00003eef@hotmail.com>
References:  <BAY3-F3Ohw2RlC6aVEp00003eef@hotmail.com>
X-Mailer: Mulberry/3.1.0 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: quoted-printable

Jeff,

The "Usage" field was meant a little bit different than description and
applicability. The description just says what it is (an IP address, a
packet counter for lost packets or a parameter within a sampling method
in PSAMP), the applicability states if the field can be used by the
data flowset the option flowset or both and finally the usage says in
which context the field is meaningful. Maybe usage is more important
in the PSAMP info model than in the IPFIX one. Let me give you an example:

We currently have defined an "intervalTime" field in the PSAMP info model.
The description says that it is the time between two samples. The
applicability says it is used in the option flowset. Finally the usage says
that it is an option for the Systematic Time Based sampling.

Regarding section 7 in PSAMP you are missing the XML Document. Actually
there is such a document and we create section 6 from this document using
XSLT like you did. In the current state we were not to sure if we should
include the XML document into the draft. This is still to be discussed
on the PSAMP mailing list.

Furthermore, as Juergen already posted on the IPFIX mailing list, we
are working together on an improved version of this XML encoding.

Regards,

Thomas

--On Donnerstag, Januar 29, 2004 10:11:47 -0800 Jeff Meyer <inetpix@msn.com>=20
wrote:

> Juergen,
>
>   I see two separate issues:
>
>    1. Adding an applicability statement to the set of information captured
> for each attribute.  Sounds like a good idea to me.  (should be [issue]
> INFO-31)
>
>    2. Segregating per flow information from exporter general information
> (i.e. Option Templates).
>
>   I'd like to do both.
>
>   I also notice in PSAMP that there is yet another field called "Usage", in
> scanning the text, it would appear to me that this typically is just a
> rewording of the "Description" and "Applicability" fields.  So I would
> question whether it is needed.
>
>   Finally, I see there is text around XML in a section 7 in PSAMP, but no
> actual XML doc.  Did the group ever create an XML-Schema?  Or did they fill
> in the text based "template" from section 6?
>
> -- Jeff
>
>
>> From: Juergen Quittek <quittek@ccrle.nec.de>
>> To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] [issue] INFO-25  Options data is not addressed in
>> info-model
>> Date: Thu, 29 Jan 2004 12:37:09 +0100
>>
>> Jeff,
>>
>> I agree.  In the PSAMP INFO model <draft-ietf-psamp-info-00.txt>
>> there is already an additional entry in the list of properties of
>> en information elements to be specified for each element:
>>
>>    Applicability - a statement in which flow records the attribute is
>>      used. An attribute can be exported in a data flow record, a
>>      options data flow record or both.
>>
>> We should add this property also to the IPFIX INFO model to be stated
>> for each info element.
>>
>>    Juergen
>>
>>
>> --On 26.01.2004 23:19 Uhr -0800 Jeff Meyer wrote:
>>
>>> Currently the content of the information model deals with information
>>> elements related
>>> to a single flow (or possibly aggregated set of flows).
>>>
>>> There is another class of information which pertains to details about the
>>> exporter itself.
>>> (e.g. total number of flows exported, drops and other items).  Some of
>>> these are
>>> currently described in the protocol draft under the discussion of "Option
>>> Templates".
>>>
>>> These information elements should be described in the information model
>>> as  well. Probably
>>> in a separate section dealing with "Exporter Detail Information".
>>>
>>> -- Jeff Meyer
>>>
>>> _________________________________________________________________
>>> Get a FREE online virus check for your PC here, from McAfee.
>>> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963
>>>
>>>
>>> --
>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>> body
>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>> "unsubscribe ipfix" in message body
>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>
>>
>>
>>
>> --
>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>> body
>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>> "unsubscribe ipfix" in message body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>
> _________________________________________________________________
> Check out the new MSN 9 Dial-up =97 fast & reliable Internet access with
> prime features! =
http://join.msn.com/?pgmarket=3Den-us&page=3Ddialup/home&ST=3D1
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
> body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 30 11:53:39 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27314
	for <ipfix-archive@lists.ietf.org>; Fri, 30 Jan 2004 11:53:39 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmbXC-0000Om-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jan 2004 10:30:22 -0600
Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmbXB-0000O7-00
	for ipfix@net.doit.wisc.edu; Fri, 30 Jan 2004 10:30:21 -0600
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0UGUEJ07292
	for <ipfix@net.doit.wisc.edu>; Fri, 30 Jan 2004 10:30:15 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <C6W7JQSW>; Fri, 30 Jan 2004 16:54:55 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC480@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "'stbryant@cisco.com'" <stbryant@cisco.com>,
        Juergen Quittek
	 <quittek@ccrle.nec.de>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        allison mankin <mankin@isi.edu>
Cc: ipfix@net.doit.wisc.edu
Subject: [ipfix] RE: IPFIX requirements - security
Date: Fri, 30 Jan 2004 16:54:53 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Stewart, inline

> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com]
> Sent: woensdag 28 januari 2004 12:45
> To: Juergen Quittek; bwijnen@lucent.com; allison mankin
> Cc: ipfix@net.doit.wisc.edu
> Subject: IPFIX requirements - security
> 
> 
> I believe that the security requirements (below) which were
> enhanced by the IESG are an unreasonable burden on many
> implementations.
> 
Unreasonable for the IMPLEMENTATIONs?

Note that the requirements are mainly stsated such that 
the protocol MUST support. So that means you MUST implement
if you want to claim compliance. 

Of course someone who deploys it can choose to not use the
security features of the protocol but instead use dedicated
(and protected) links. 

> The new requirements lack a measure of appropriateness which
> needs to be incorporated in the definition.
> 
> For example there is no point in providing greater
> confidentiality in the IPFIX protocol than exists at the
> observation point itself.
> 
Is that true?
If the observation point is in a secure place, and the flow is
going to another secure place via a secure link, but you export 
the data via an unsecure path to some collector, than that seems
incorrect to me.

> There is no point in providing a level of integrity or
> authenticity that exceeds the requirements of the collecting
> application.
> 
> Setting the baseline for operation over the public Internet
> leads to the inevitable conclusion that IPFIX MUST be run
> over IPsec, but that is absurd in situations where the
> network design precludes the possibility of data leakage
> (for example where the IPFIX traffic is carried over a
> private management network).
> 
The fact that the protocol spec and conformant implementations
support/rpvide-for a way of secure transmission does not mean that
deployment needs to utilize those functions if they have made
sure that the (dedicated) links over which the exported data travels
are (physically) secure.

> The net result of setting the bar at this level will be
> either late and unnecessarily costly deployment of IPFIX,
> or (more likely) the widespread deployment of non-compliant
> IPFIX, thereby bringing the RFC into disrepute.
> 
I hope other people can speak up on this too, eitehr agreeing
or dis-agreeing with you. 

> Section 6.3.3 should therefore be reworded to something
> of the following form:
> 
> IPFIX data transferred from an exporting process to a
> collecting process MUST NOT degrade the confidentiality of
> the packet flows at the observation point.
> 
> The method of transferring IPFIX data from the exporting
> process to the collecting process MUST provide the level
> of data integrity required by the collecting application.
> 
> The authenticity of IPFIX data transferred from an exporting
> process to a collecting process MUST be sufficient to meet
> the application needs at the collector.
> 
I do not agree with the above.

Bert
> - Stewart
> 
> 
> Original text for reference:
> 
> ====================
> 
> 6.3.3.  Security
> 
>     Confidentiality of IPFIX data transferred from an 
> exporting process
>     to a collecting process MUST be ensured.
> 
>     Integrity of IPFIX data transferred from an exporting process to a
>     collecting process MUST be ensured.
> 
>     Authenticity of IPFIX data transferred from an exporting 
> process to a
>     collecting process MUST be ensured.
> 
> =====================
> 
> 10.  Security Considerations
> 
>     An IPFIX protocol must be capable of transporting data over the
>     public Internet.  Therefore it cannot be excluded that an attacker
>     captures or modifies packets or inserts additional packets.
> 

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 30 12:01:32 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28083
	for <ipfix-archive@lists.ietf.org>; Fri, 30 Jan 2004 12:01:31 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmbZU-0000R1-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jan 2004 10:32:44 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmbZS-0000Qt-00
	for ipfix@net.doit.wisc.edu; Fri, 30 Jan 2004 10:32:43 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0UGWcNA014587
	for <ipfix@net.doit.wisc.edu>; Fri, 30 Jan 2004 17:32:40 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0UGWcGL014585
	for <ipfix@net.doit.wisc.edu>; Fri, 30 Jan 2004 17:32:38 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0UGWbN8014581; Fri, 30 Jan 2004 17:32:38 +0100 (CET)
Received: from [10.1.1.171] (n-quittek.office [10.1.1.171])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 76516FF95C; Fri, 30 Jan 2004 17:32:36 +0100 (CET)
Date: Fri, 30 Jan 2004 17:32:52 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations
Message-ID: <2147483647.1075483972@[10.1.1.171]>
In-Reply-To: <2147483647.1075471150@[10.1.1.171]>
References:  <BAY3-F35u23LiC1h1jY00023ba8@hotmail.com> <2147483647.1075471150@[10.1.1.171]>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========2147489275=========="
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

--==========2147489275==========
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Jeff and all,

Here is an alternative suggestion for the XML representation of the
info model that I developed together with Thomas, one of the editors of
the PSAMP info model.  This XML representation of the info model uses
an XML document (ipfix.xml) instead of an XML schema for specifying
the IPFIX information elements (or fields as the IPFIX protocol document
calls them). It just shows the first 11 elements defined in the current draft,
but this is enough to show how this XML format looks like.

File ipfix.xml can be used for automatically generating Section 6 of
the INFO model document as well as the XML schema used for the previous
version.  The difference is that it uses abstract data types (as a data
model should) instead of concrete ones.

In addition, file ipfix.xsd contains an XML schema, that can be used
for validating the ipfix.xml file. It defines the properties of fields/
information elements that are used in ipfix.xml and it also includes
a definition of the abstract data types used in ipfix.xml.

A nice consequence is that now not just Section 6 (field definitions)
but also Section 3 (Properties of an IPFIX Flow Attribute) and Section 4
(Type Space) can be generated out of XML input.

While section 6 is generated from ipfix.xml, Sections 3 and 4 are
generated from ipfix.xsd.

Also the XML schema, we used for the previous versions of the INFO model
can be generated out of the info model given in ipfix.xml.  You just have
to define a mapping of the used abstract data types to concrete ones,
such as the IPDR definitions of IPv4 and IPv6 addresses.

Conclusion:
- This version is a pure data model using abstract data types and without
  any data encodings.
- It does not have dependencies on external data type definitions by IPDR.
- We do not loose anything, because the XML schema, we used so far
  (including XML data types) can be generated automatically.

Cheers,

    Juergen

--On 30.01.2004 13:59 Uhr +0100 Juergen Quittek wrote:

> Jeff,
>
> --On 29.01.2004 10:20 Uhr -0800 Jeff Meyer wrote:
>
>> Juergen,
>>
>>   XML-Schema can be thought of as a pure Informaiton Model.
>
> Of course we can say:
>   "Here is a combined info and data model, please ignore the data model part,
>    because this standard is just about the info model."
>
> But this appears to be - at least - curious.
>
>> XML-Schema and XML also define productions which can be used to create
>> instance documents which are a data model and encoded in ASCII.
>
> This is what people call a data model.
>
>> IPDR takes full advantage of this by providing both
>> ASCII and Binary encodings from the same information model.
>> I.e. XML-Schema CAN be used AS IS as a pure information model.
>
> Yes and we can have exactly the same with what I suggested.
> The current version of the IPFIX INFO model does not contain
> a binary encoding, but it does contain an ASCII encoding.
>
>>   Think of ASN.1 which has a Syntax and various encoding rules such
>> as BER, DER and others (even an XER).  At some point you need to
>> formally define something, but that DOES NOT mean that the ASN.1
>> syntax is just a BINARY encoding model nor is it just
>> one encoding model.  Hence it IS separate from encoding.
>>
>>   I view XML-Schema as the ASN.1 of the 21st century, only with a
>> much richer set of off the shelf and often free tools and other
>> interoperable components.
>
> I am sure you do not claim to inherit all properties of ASN.1 ;-)
>
>>   Renaming things which are well defined (e.g. int) to duplicate
>> names (e.g. ipfix-int) is just a lot of unnecessary rework.
>> The temptation to simply redefine things is often large for
>> engineers.  However in the long run reusing existing work
>> increases the likelihood that people will converge on certain
>> key patterns.
>
> It is not just renaming.  It is replacing the concrete XML data type
> with an abstract one that can be mapped to XML as well as to many other
> domains.  And if you look at other INFO models, for example defined
> in CIM by the DMTF, always abstract data types are used in info models.
> Concrete ones are just used in data models.
>
> But even if you just consider it as renaming, it solves some problems.
>   [And having worked as software engineer, I know that renaming (e.g. by
>    endless sets of #DEFINEs in C and C++ is not really unusual.]
> The problems we can solve are
>
>   1. We can replace 'hexBinary' by 'octetArray' or something else.
>      Why should a binary data type use 'hex' in its name, if not ONLY
>      with respect to its ASCII data encoding?  And the encoding that really
>      is of importance for IPFIX standardization is the binary encoding
>      by the protocol.
>
>   2. We do not have to refer to an IPDR document as a normative reference.
>      This has three implications:
>
>      First, I do not know if this is (so far) possible at all for IETF
>      standard track documents.
>
>      Second, I am not sure if the IPDR definition of IPv4 addresses and IPv6
>      addresses is what the IETF would like to use.  It does not make sense
>      to import IPv4 address XML encoding from the IPDR definitions in one
>      IETF standard and to use another source in another IETF standard.
>
>      Third, if we use our own ABSTRACT data types, users can more easily
>      choose other XML encodings than the one promoted by IPDR.
>      [Nothing against IPDR. I like it very much and my company is a member]
>      Management systems and database builders/integrators may/will already
>      have their own (XML) data types for flow recording. If we use an
>      abstract data type we do not explicitly request them to use the
>      IPDR definitions.
>
>
>     Juergen
>
>> -- Jeff
>>
>>
>>> From: Juergen Quittek <quittek@ccrle.nec.de>
>>> To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>>> Subject: Re: [ipfix] [issue] INFO-29  Namespace definitions may need IANA
>>> considerations
>>> Date: Thu, 29 Jan 2004 13:31:19 +0100
>>>
>>> Jeff,
>>>
>>> I suggest to follow a completely different way of solving this
>>> problems such that everybody get what is needed.
>>>
>>> I see the cause in our dispute that the Appendix of the INFO model
>>> document is NOT just an information model, but a data model.
>>>
>>> As you argued well some time ago, it is a bad idea specifying
>>> binary encodings in the info model document, because this would
>>> already be a data model, which may vary among different protocols
>>> that potentially use the IPFIX INFO model.
>>>
>>> So, it is completely correct, that the binary encoding has become
>>> a part of the IPFIX PROTOCOL document.  But still the IPFIX INFO
>>> model document contains a data model: the XML ASCII encoding for
>>> each information element. This is a data model. IMHO this is wrong!
>>>
>>> We should follow a clean approach by just specifying an
>>> information model.  This would solve several of the open issues
>>> we are discussing, including the name space problem (iprd:),
>>> because we get completely independent of these data encoding issues
>>> and still can support IPDR data types in XML-based applications.
>>>
>>> Here is my suggestion:
>>>
>>> Currently, the Appendix is an XML schema defining which fixes ASCII
>>> encodings for each information element.  I suggest to replace this
>>> XML schema by an XML document.  The document would consist of a set
>>> of XML element, each of them specifying a single information elements
>>> with a set of attributes and/or contained XML elements exactly
>>> covering all properties of information elements as defined in section 3.
>>> (We can use a small, simple XML schema for checking consistency of this
>>> XML document.)
>>>
>>> Information elements defined this way would not have a standard XML,
>>> IPDR, or other data type (data model should be separated from info model),
>>> but would be defined just by English text, for example
>>>  ipfix-int: integer value in the range of -2147483648 to 2147483647
>>>  ipfix-dateTime: number of seconds since Jan 1st, 1970, 00:00 h
>>>  ipfix-ipv4address: integral representation of a 32 bit IPv4 address
>>>  ...
>>> We would create our own IPFIX type space for the information elements.
>>>
>>> Based on this pure information model, we can use XSLT (as we do it now)
>>> to generate all the text in Section 6 describing the information elements.
>>>
>>> Now, if you want to realize an XML-based application, you can take the
>>> new XML document and use XSLT for automatic generation of a schema, such
>>> as the one we have in the Appendix of the current version of the INFO model
>>> document.  You see, you still have all the advantages of the machine-
>>> readability and all opportunities to generate IPFIX XML parsers
>>> automatically.
>>> But with the suggested change you would also have a clean information model
>>> in the IPFIX INFO document avoiding all discussions on whether or not to
>>> use the IPDR data types.
>>>
>>> I am currently working together with Thomas, editor of the PSAMP INFO
>>> model, to implement the idea sketched above. We will send an example to
>>> this list in a few days.
>>>
>>> Regards,
>>>
>>>    Juergen
>>>
>>>
>>> --On 27.01.2004 23:55 h -0800 Jeff Meyer wrote:
>>>
>>>> The current info-model-02 specification contains references to XML type
>>>> names and semantics borrowed directly from the XML-Schema specification as
>>>> well as extensions.
>>>>
>>>> Currently these extensions borrow from existing work of IPDR as well as
>>>> newly identified types currently specific to IPFIX.
>>>>
>>>> There are a few ways to address this.
>>>>
>>>> The following e-mail thread discusses the options and opinion of this
>>>> editor as well as opinions from Andrew Norton who is involved in IETF's
>>>> and IANA's work in utilizing XML in RFC's.
>>>>
>>>>
>>>> Jeff,
>>>>
>>>> It would seem that this is all a matter of "taste" as any of these options
>>>> technically work.  Personally I would go with option 3; though it requires
>>>> more coordination between organizations, to an outsider it would seem more
>>>> cohesive.
>>>>
>>>> There is a practical difference between option 1 and option 3 in terms of
>>>> setting the standard.  With option 3, if IPDR upgrades their standard, the
>>>> IPFIX group needs to do nothing to incorporate the changes.  However, with
>>>> option 1, IPFIX will have to
>>>> standardize a new schema and issue new RFC's.
>>>>
>>>> -andy
>>>>
>>>> Jeff Meyer wrote:
>>>>     Hi Andy,
>>>>
>>>> I wanted to get your opinion on extending the XML-Schema type system for
>>>> some specific information modeling requirements encountered by the IPFIX
>>>> working group.
>>>>
>>>> IPFIX currently reuses about 15 types from XML-Schema directly, however
>>>> there are several types which are worthwile to distinguish from an IPFIX
>>>> persepective which are not defined by XML-Schema.
>>>>
>>>> These include types to identify timestamps of specific resolution (e.g.
>>>> mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and one for
>>>> UUIDs.
>>>>
>>>> Today most of these extension types are defined in the public NDM-U 3.1.1
>>>> specification from the industry consortium called IPDR.org.  There are a
>>>> couple which are not are related to the high resolution timestamps (uSec
>>>> and nSec).
>>>>
>>>> The NDM-U 3.1.1 specificaiton is avaiable at
>>>> http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically section
>>>> A.4.4.
>>>>
>>>> The IPFIX-Info reference is available at:
>>>>
>>>> http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#anchor4
>>>>
>>>>
>>>> This is a link to the specific secion in the HTML format of the info model
>>>> based on RFC2629.
>>>>
>>>>
>>>> The quesion at hand is whether to follow one of the following 3 options:
>>>>
>>>>    1. have a single XML-Schema which defines the extension types relevant
>>>> to IPFIX and contained in the IPFIX namespace
>>>>    2. reference the existing types targeted by IPDR and add only the new
>>>> types specific to the IPFIX Schema
>>>>    3. petition IPDR to define the remaining two IPFIX types for
>>>> timestamps in their upcoming 3.5 specification (likely timeframe Feb. or
>>>> March)
>>>>
>>>> I get the impression from IPFIX discussions that referencing IPDR is
>>>> something that some vocal participants find objectionable, i.e. they would
>>>> prefer to see option 1.
>>>>
>>>> My personal preference would be to go with option 3 or 2.  I believe 3 is
>>>> doable and would reduce the number of places where people have to look for
>>>> things.  Option 1 I see as creating some confusion in the space, but
>>>> ultimately addressable through XSL
>>>> or other mapping functions, if that's what it takes to get consensus.
>>>>
>>>>
>>>> Any guidance on your part would be appreciated.
>>>>
>>>> Regards,
>>>>
>>>> Jeff Meyer
>>>>
>>>> _________________________________________________________________
>>>> Get a FREE online virus check for your PC here, from McAfee.
>>>> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963
>>>>
>>>>
>>>> --
>>>> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>>> body
>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>> "unsubscribe ipfix" in message body
>>>> Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>>
>>>
>>
>> _________________________________________________________________
>> Find high-speed =91net deals ? comparison-shop your local providers here. https://broadband.msn.com
>>
>
>
>
>
>
> --
> Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/




--==========2147489275==========
Content-Type: application/octet-stream; name="ipfix.xml"
Content-Disposition: attachment; filename="ipfix.xml"; size=4079
Content-Transfer-Encoding: base64

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGZpZWxkRGVmaW5pdGlvbnMg
eG1sbnM9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaXBmaXgiPgogIDxmaWVsZCBuYW1lPSJzb3VyY2VB
ZGRyZXNzVjQiIGRhdGFUeXBlPSJpcHY0QWRkcmVzcyIKICAgICAgICAgZmllbGRUeXBlPSI4IiBh
cHBsaWNhYmlsaXR5PSJhbGwiIHN0YXR1cz0iY3VycmVudCI+CiAgICA8ZGVzY3JpcHRpb24+CiAg
ICAgIElQdjQgc291cmNlIGFkZHJlc3MgdGFrZW4gZnJvbSB0aGUgcGFja2V0IGhlYWRlci4KICAg
IDwvZGVzY3JpcHRpb24+CiAgICA8dXNhZ2U+CiAgICA8L3VzYWdlPgogIDwvZmllbGQ+CgogIDxm
aWVsZCBuYW1lPSJzb3VyY2VBZGRyZXNzVjYiIGRhdGFUeXBlPSJpcHY2QWRkcmVzcyIKICAgICAg
ICAgZmllbGRUeXBlPSIyNyIgYXBwbGljYWJpbGl0eT0iYWxsIiBzdGF0dXM9ImN1cnJlbnQiPgog
ICAgPGRlc2NyaXB0aW9uPgogICAgICBJUHY2IHNvdXJjZSBhZGRyZXNzIHRha2VuIGZyb20gdGhl
IHBhY2tldCBoZWFkZXIuCiAgICA8L2Rlc2NyaXB0aW9uPgogICAgPHVzYWdlPgogICAgPC91c2Fn
ZT4KICA8L2ZpZWxkPgoKICA8ZmllbGQgbmFtZT0iZGVzdGluYXRpb25BZGRyZXNzVjQiIGRhdGFU
eXBlPSJpcHY0QWRkcmVzcyIKICAgICAgICAgZmllbGRUeXBlPSI5IiBhcHBsaWNhYmlsaXR5PSJh
bGwiIHN0YXR1cz0iY3VycmVudCI+CiAgICA8ZGVzY3JpcHRpb24+CiAgICAgIElQdjQgZGVzdGlu
YXRpb24gYWRkcmVzcyB0YWtlbiBmcm9tIHRoZSBwYWNrZXQgaGVhZGVyLgogICAgPC9kZXNjcmlw
dGlvbj4KICAgIDx1c2FnZT4KICAgIDwvdXNhZ2U+CiAgPC9maWVsZD4KCiAgPGZpZWxkIG5hbWU9
ImRlc3RpbmF0aW9uQWRkcmVzc1Y2IiBkYXRhVHlwZT0iaXB2NkFkZHJlc3MiCiAgICAgICAgIGZp
ZWxkVHlwZT0iMjgiIGFwcGxpY2FiaWxpdHk9ImFsbCIgc3RhdHVzPSJjdXJyZW50Ij4KICAgIDxk
ZXNjcmlwdGlvbj4KICAgICAgSVB2NiBkZXN0aW5hdGlvbiBhZGRyZXNzIHRha2VuIGZyb20gdGhl
IHBhY2tldCBoZWFkZXIuCiAgICA8L2Rlc2NyaXB0aW9uPgogICAgPHVzYWdlPgogICAgPC91c2Fn
ZT4KICA8L2ZpZWxkPgoKICA8ZmllbGQgbmFtZT0icHJvdG9jb2xJZGVudGlmaWVyIiBkYXRhVHlw
ZT0ib2N0ZXQiCiAgICAgICAgIGZpZWxkVHlwZT0iNCIgYXBwbGljYWJpbGl0eT0iYWxsIiBzdGF0
dXM9ImN1cnJlbnQiCiAgICAgICAgIGRhdGFUeXBlU2VtYW50aWNzPSJpZGVudGlmaWVyIj4KICAg
IDxkZXNjcmlwdGlvbj4KICAgICAgUHJvdG9jb2wgbnVtYmVyIGlkZW50aWZpZWQgaW4gdGhlIElQ
IHBhY2tldC4KICAgICAgSW4gdGhlIEludGVybmV0IFByb3RvY29sIHZlcnNpb24gNCAoSVB2NCkg
W1JGQzc5MV0gdGhlcmUgaXMgYSBmaWVsZCwKICAgICAgY2FsbGVkICJQcm90b2NvbCIsIHRvIGlk
ZW50aWZ5IHRoZSBuZXh0IGxldmVsIHByb3RvY29sLiAgVGhpcyBpcyBhbiA4CiAgICAgIGJpdCBm
aWVsZC4gIEluIEludGVybmV0IFByb3RvY29sIHZlcnNpb24gNiAoSVB2NikgW1JGQzE4ODNdIHRo
aXMgZmllbGQKICAgICAgaXMgY2FsbGVkIHRoZSAiTmV4dCBIZWFkZXIiIGZpZWxkLgogICAgPC9k
ZXNjcmlwdGlvbj4KICAgIDx1c2FnZT4KICAgIDwvdXNhZ2U+CiAgICA8cmVmZXJlbmNlPgogICAg
ICBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Byb3RvY29sLW51bWJlcnMKICAgIDwv
cmVmZXJlbmNlPgogIDwvZmllbGQ+CgogIDxmaWVsZCBuYW1lPSJzb3VyY2VQb3J0IiBkYXRhVHlw
ZT0idW5zaWduZWQxNiIKICAgICAgICAgZmllbGRUeXBlPSI3IiBhcHBsaWNhYmlsaXR5PSJhbGwi
IHN0YXR1cz0iY3VycmVudCIKICAgICAgICAgZGF0YVR5cGVTZW1hbnRpY3M9ImlkZW50aWZpZXIi
PgogICAgPGRlc2NyaXB0aW9uPgogICAgICBUaGlzIGluZm9ybWF0aW9uIGVsZW1lbnQgaXMgdXNl
ZCB0byByZXBvcnQgVURQIHNvdXJjZSBwb3J0CiAgICAgIG9yIFRDUCBkZXN0aW5hdGlvbiBwb3J0
IGFzIHRha2VuIGZyb20gdGhlIElQIGhlYWRlci4KICAgIDwvZGVzY3JpcHRpb24+CiAgICA8dXNh
Z2U+CiAgICA8L3VzYWdlPgogICAgPHJlZmVyZW5jZT4KICAgICAgUkZDIDc2OCwgUkZDIDc5My4K
ICAgIDwvcmVmZXJlbmNlPgogIDwvZmllbGQ+CgogIDxmaWVsZCBuYW1lPSJkZXN0aW5hdGlvblBv
cnQiIGRhdGFUeXBlPSJ1bnNpZ25lZDE2IgogICAgICAgICBmaWVsZFR5cGU9IjExIiBhcHBsaWNh
YmlsaXR5PSJhbGwiIHN0YXR1cz0iY3VycmVudCIKICAgICAgICAgZGF0YVR5cGVTZW1hbnRpY3M9
ImlkZW50aWZpZXIiPgogICAgPGRlc2NyaXB0aW9uPgogICAgICBUaGlzIGluZm9ybWF0aW9uIGVs
ZW1lbnQgaXMgdXNlZCB0byByZXBvcnQgVURQIGRlc3RpbmF0aW9uIHBvcnQKICAgICAgb3IgVENQ
IGRlc3RpbmF0aW9uIHBvcnQgYXMgdGFrZW4gZnJvbSB0aGUgSVAgaGVhZGVyLgogICAgPC9kZXNj
cmlwdGlvbj4KICAgIDx1c2FnZT4KICAgIDwvdXNhZ2U+CiAgPC9maWVsZD4KCiAgPGZpZWxkIG5h
bWU9ImluZ3Jlc1BvcnQiIGRhdGFUeXBlPSJ1bnNpZ25lZDE2IgogICAgICAgICBmaWVsZFR5cGU9
IjEwIiBhcHBsaWNhYmlsaXR5PSJhbGwiIHN0YXR1cz0iY3VycmVudCIKICAgICAgICAgZGF0YVR5
cGVTZW1hbnRpY3M9ImlkZW50aWZpZXIiPgogICAgPGRlc2NyaXB0aW9uPgogICAgICBUaGUgaW5k
ZXggb2YgdGhlIElQIGludGVyZmFjZSB3aGVyZSB0aGUgcGFja2V0cyBmb3IgdGhlCiAgICAgIGZs
b3cgYXJlIGJlaW5nIHJlY2VpdmVkLiAgVGhlIGludGVyZmFjZSBpbmRleCBpcyBkZWZpbmVkCiAg
ICAgIGJ5IHRoZSBJRi1NSUIgbW9kdWxlIGFzIGlmSW5kZXguCiAgICA8L2Rlc2NyaXB0aW9uPgog
ICAgPHVzYWdlPgogICAgPC91c2FnZT4KICA8L2ZpZWxkPgoKICA8ZmllbGQgbmFtZT0iZWdyZXNQ
b3J0IiBkYXRhVHlwZT0idW5zaWduZWQxNiIKICAgICAgICAgZmllbGRUeXBlPSIxNCIgYXBwbGlj
YWJpbGl0eT0iYWxsIiBzdGF0dXM9ImN1cnJlbnQiCiAgICAgICAgIGRhdGFUeXBlU2VtYW50aWNz
PSJpZGVudGlmaWVyIj4KICAgIDxkZXNjcmlwdGlvbj4KICAgICAgVGhlIGluZGV4IG9mIHRoZSBJ
UCBpbnRlcmZhY2Ugd2hlcmUgdGhlIHBhY2tldHMgZm9yIHRoZQogICAgICBmbG93IGFyZSBiZWlu
ZyBzZW50LiAgVGhlIGludGVyZmFjZSBpbmRleCBpcyBkZWZpbmVkCiAgICAgIGJ5IHRoZSBJRi1N
SUIgbW9kdWxlIGFzIGlmSW5kZXguCiAgICA8L2Rlc2NyaXB0aW9uPgogICAgPHVzYWdlPgogICAg
PC91c2FnZT4KICAgIDxyZWZlcmVuY2U+CiAgICAgIFJGQyAyODYzLgogICAgPC9yZWZlcmVuY2U+
CiAgPC9maWVsZD4KCiAgPGZpZWxkIG5hbWU9InBhY2tldENvdW50IiBkYXRhVHlwZT0idW5zaWdu
ZWQzMiIKICAgICAgICAgZmllbGRUeXBlPSIyIiBhcHBsaWNhYmlsaXR5PSJhbGwiIHN0YXR1cz0i
Y3VycmVudCIKICAgICAgICAgZGF0YVR5cGVTZW1hbnRpY3M9ImNvdW50ZXIiPgogICAgPGRlc2Ny
aXB0aW9uPgogICAgICBDb250YWlucyB0aGUgbnVtYmVyIG9mIHBhY2tldHMgaW4gdGhlIGZsb3cs
IGluIHRoZSAiZG93bnN0cmVhbSIKICAgICAgKHNvdXJjZS10by1kZXN0aW5hdGlvbikgZGlyZWN0
aW9uLgogICAgPC9kZXNjcmlwdGlvbj4KICAgIDx1c2FnZT4KICAgIDwvdXNhZ2U+CiAgICA8dW5p
dHM+CiAgICAgIFBhY2tldHMKICAgIDwvdW5pdHM+CiAgPC9maWVsZD4KCiAgPGZpZWxkIG5hbWU9
Im9jdGV0Q291bnQiIGRhdGFUeXBlPSJ1bnNpZ25lZDMyIgogICAgICAgICBmaWVsZFR5cGU9IjEi
IGFwcGxpY2FiaWxpdHk9ImFsbCIgc3RhdHVzPSJjdXJyZW50IgogICAgICAgICBkYXRhVHlwZVNl
bWFudGljcz0iY291bnRlciI+CiAgICA8ZGVzY3JpcHRpb24+CiAgICAgIENvbnRhaW5zIHRoZSBu
dW1iZXIgb2Ygb2N0ZXRzIGluIHRoZSBmbG93LCBpbiB0aGUgImRvd25zdHJlYW0iCiAgICAgIChz
b3VyY2UtdG8tZGVzdGluYXRpb24pIGRpcmVjdGlvbi4KICAgIDwvZGVzY3JpcHRpb24+CiAgICA8
dXNhZ2U+CiAgICA8L3VzYWdlPgogICAgPHVuaXRzPgogICAgICBPY3RldHMKICAgIDwvdW5pdHM+
CiAgPC9maWVsZD4KPC9maWVsZERlZmluaXRpb25zPgo=

--==========2147489275==========
Content-Type: application/octet-stream; name="ipfix.xsd"
Content-Disposition: attachment; filename="ipfix.xsd"; size=13288
Content-Transfer-Encoding: base64

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNjaGVtYSB4bWxucz0iaHR0
cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiCiAgICAgICAgeG1sbnM6aXBmaXg9Imh0dHA6
Ly93d3cuaWV0Zi5vcmcvaXBmaXgiCiAgICAgICAgdGFyZ2V0TmFtZXNwYWNlPSJodHRwOi8vd3d3
LmlldGYub3JnL2lwZml4IgogICAgICAgIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIj4K
CjxzaW1wbGVUeXBlIG5hbWU9ImRhdGFUeXBlIj4KICA8cmVzdHJpY3Rpb24gYmFzZT0ic3RyaW5n
Ij4KICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0ib2N0ZXQiPgogICAgICA8YW5ub3RhdGlvbj4KICAg
ICAgICA8ZG9jdW1lbnRhdGlvbj4KICAgICAgICAgIFRoZSB0eXBlICJ1bnNpZ25lZEJ5dGUiIHJl
cHJlc2VudHMgYSBub24tbmVnYXRpdmUgaW50ZWdlciB2YWx1ZQogICAgICAgICAgaW4gdGhlIHJh
bmdlIG9mIDAgdG8gMjU1LgogICAgICAgIDwvZG9jdW1lbnRhdGlvbj4KICAgICAgPC9hbm5vdGF0
aW9uPgogICAgPC9lbnVtZXJhdGlvbj4KICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0idW5zaWduZWQx
NiI+CiAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgIDxkb2N1bWVudGF0aW9uPgogICAgICAgICAg
VGhlIHR5cGUgInVuc2lnbmVkMTYiIHJlcHJlc2VudHMgYSBub24tbmVnYXRpdmUgaW50ZWdlciB2
YWx1ZQogICAgICAgICAgaW4gdGhlIHJhbmdlIG9mIDAgdG8gNjU1MzUuCiAgICAgICAgPC9kb2N1
bWVudGF0aW9uPgogICAgICA8L2Fubm90YXRpb24+CiAgICA8L2VudW1lcmF0aW9uPgogICAgPGVu
dW1lcmF0aW9uIHZhbHVlPSJ1bnNpZ25lZDMyIj4KICAgICAgPGFubm90YXRpb24+CiAgICAgICAg
PGRvY3VtZW50YXRpb24+CiAgICAgICAgICBUaGUgdHlwZSAidW5zaWduZWQzMiIgcmVwcmVzZW50
cyBhIG5vbi1uZWdhdGl2ZSBpbnRlZ2VyIHZhbHVlCiAgICAgICAgICBpbiB0aGUgcmFuZ2Ugb2Yg
MCB0byA0Mjk0OTY3Mjk1LgogICAgICAgIDwvZG9jdW1lbnRhdGlvbj4KICAgICAgPC9hbm5vdGF0
aW9uPgogICAgPC9lbnVtZXJhdGlvbj4KICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0idW5zaWduZWQ2
NCI+CiAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgIDxkb2N1bWVudGF0aW9uPgogICAgICAgICAg
VGhlIHR5cGUgInVuc2lnbmVkNjQiIHJlcHJlc2VudHMgYSBub24tbmVnYXRpdmUgaW50ZWdlciB2
YWx1ZQogICAgICAgICAgaW4gdGhlIHJhbmdlIG9mIDAgdG8gMTg0NDY3NDQwNzM3MDk1NTE2MTUu
CiAgICAgICAgPC9kb2N1bWVudGF0aW9uPgogICAgICA8L2Fubm90YXRpb24+CiAgICA8L2VudW1l
cmF0aW9uPgogICAgPGVudW1lcmF0aW9uIHZhbHVlPSJmbG9hdDMyIj4KICAgICAgPGFubm90YXRp
b24+CiAgICAgICAgPGRvY3VtZW50YXRpb24+CiAgICAgICAgICBUaGUgdHlwZSAiZmxvYXQzMiIg
Y29ycmVzcG9uZHMgdG8gYW4gSUVFRSBzaW5nbGUtcHJlY2lzaW9uCiAgICAgICAgICAzMi1iaXQg
ZmxvYXRpbmcgcG9pbnQgdHlwZS4KICAgICAgICA8L2RvY3VtZW50YXRpb24+CiAgICAgIDwvYW5u
b3RhdGlvbj4KICAgIDwvZW51bWVyYXRpb24+CiAgICA8ZW51bWVyYXRpb24gdmFsdWU9ImJvb2xl
YW4iPgogICAgICA8YW5ub3RhdGlvbj4KICAgICAgICA8ZG9jdW1lbnRhdGlvbj4KICAgICAgICAg
IFRoZSB0eXBlICJib29sZWFuIiByZXByZXNlbnRzIGEgYmluYXJ5IHZhbHVlLgogICAgICAgIDwv
ZG9jdW1lbnRhdGlvbj4KICAgICAgPC9hbm5vdGF0aW9uPgogICAgPC9lbnVtZXJhdGlvbj4KICAg
IDxlbnVtZXJhdGlvbiB2YWx1ZT0ib2N0ZXRBcnJheSI+CiAgICAgIDxhbm5vdGF0aW9uPgogICAg
ICAgIDxkb2N1bWVudGF0aW9uPgogICAgICAgICAgVGhlIHR5cGUgIm9jdGV0QXJyYXkgcmVwcmVz
ZW50cyBhIGZpbml0ZSBsZW5ndGggc3RyaW5nIG9mIG9jdGV0cy4KICAgICAgICA8L2RvY3VtZW50
YXRpb24+CiAgICAgIDwvYW5ub3RhdGlvbj4KICAgIDwvZW51bWVyYXRpb24+CiAgICA8ZW51bWVy
YXRpb24gdmFsdWU9InN0cmluZyI+CiAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgIDxkb2N1bWVu
dGF0aW9uPgogICAgICAgICAgVGhlIHR5cGUgInN0cmluZyIgcmVwcmVzZW50cyBhIGZpbml0ZSBs
ZW5ndGggc3RyaW5nIG9mIHZhbGlkCiAgICAgICAgICBjaGFyYWN0ZXJzIGZyb20gdGhlIFVuaWNv
ZGUgY2hhcmFjdGVyIGVuY29kaW5nIHNldC4gVW5pY29kZSBhbGxvd3MKICAgICAgICAgIGZvciBB
U0NJSSBhbmQgbWFueSBvdGhlciBpbnRlcm5hdGlvbmFsIGNoYXJhY3RlciBzZXRzIHRvIGJlIHVz
ZWQuIEl0CiAgICAgICAgICBpcyBleHBlY3RlZCB0aGF0IHN0cmluZ3Mgd2lsbCBiZSBlbmNvZGVk
IGluIFVURi04IGZvcm1hdCwgd2hpY2ggaXMKICAgICAgICAgIGlkZW50aWNhbCBpbiBlbmNvZGlu
ZyBmb3IgVVNBU0NJSSBjaGFyYWN0ZXJzLCBidXQgYWxzbyBhY2NvbW9kYXRlcwogICAgICAgICAg
b3RoZXIgVW5pY29kZSBtdWx0aWJ5dGUgY2hhcmFjdGVycy4KICAgICAgICA8L2RvY3VtZW50YXRp
b24+CiAgICAgIDwvYW5ub3RhdGlvbj4KICAgIDwvZW51bWVyYXRpb24+CiAgICA8ZW51bWVyYXRp
b24gdmFsdWU9ImRhdGVUaW1lU2Vjb25kcyI+CiAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgIDxk
b2N1bWVudGF0aW9uPgogICAgICAgICAgVGhlIHR5cGUgImRhdGVUaW1lU2Vjb25kcyIgcmVwcmVz
ZW50cyBhIHRpbWUgdmFsdWUgaGF2aW5nIGEKICAgICAgICAgIHByZWNpc2lvbiBvZiBzZWNvbmRz
IGFuZCBub3JtYWxpemVkIHRvIHRoZSBHTVQgdGltZXpvbmUuCiAgICAgICAgICBTdWNoIHR5cGVz
IGFyZSBpbiBjb21tb24gdXNlIG9uIG1hbnkgT3BlcmF0aW5nIFN5c3RlbXMgYW5kCiAgICAgICAg
ICBoYXZlIHRoZSBhZHZhbnRhZ2UgdGhhdCB0aGV5IGNhbiBiZSBzdG9yZWQgaW4gMzItYml0IGlu
dGVnZXJzLgogICAgICAgIDwvZG9jdW1lbnRhdGlvbj4KICAgICAgPC9hbm5vdGF0aW9uPgogICAg
PC9lbnVtZXJhdGlvbj4KICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0iZGF0YVRpbWVNaWNyb1NlY29u
ZHMiPgogICAgICA8YW5ub3RhdGlvbj4KICAgICAgICA8ZG9jdW1lbnRhdGlvbj4KICAgICAgICAg
IFRoZSB0eXBlICJkYXRlVGltZVNlY29uZHMiIHJlcHJlc2VudHMgYSB0aW1lIHZhbHVlIGhhdmlu
ZyBhCiAgICAgICAgICBwcmVjaXNpb24gb2YgbWljcm9zZWNvbmRzIGFuZCBub3JtYWxpemVkIHRv
IHRoZSBHTVQgdGltZXpvbmUuCiAgICAgICAgPC9kb2N1bWVudGF0aW9uPgogICAgICA8L2Fubm90
YXRpb24+CiAgICA8L2VudW1lcmF0aW9uPgogICAgPGVudW1lcmF0aW9uIHZhbHVlPSJpcHY0QWRk
cmVzcyI+CiAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgIDxkb2N1bWVudGF0aW9uPgogICAgICAg
ICAgVGhlIHR5cGUgImlwdjRBZGRyIiByZXByZXNlbnRzIGEgdmFsdWUgb2YgYW4gSVB2NCBhZGRy
ZXNzLgogICAgICAgICAgVGhlc2UgYWRkcmVzc2VzIGFyZSB0eXBpY2FsbHkgc3RvcmVkIGFzIDMy
LWJpdCBpbnRlZ2Vycy4KICAgICAgICA8L2RvY3VtZW50YXRpb24+CiAgICAgIDwvYW5ub3RhdGlv
bj4KICAgIDwvZW51bWVyYXRpb24+CiAgICA8ZW51bWVyYXRpb24gdmFsdWU9ImlwdjZBZGRyZXNz
Ij4KICAgICAgPGFubm90YXRpb24+CiAgICAgICAgPGRvY3VtZW50YXRpb24+CiAgICAgICAgICBU
aGUgdHlwZSAiaXB2NkFkZHIiIHJlcHJlc2VudHMgYSB2YWx1ZSBvZiBhbiBJUHY2IGFkZHJlc3Mu
CiAgICAgICAgPC9kb2N1bWVudGF0aW9uPgogICAgICA8L2Fubm90YXRpb24+CiAgICA8L2VudW1l
cmF0aW9uPgogIDwvcmVzdHJpY3Rpb24+Cjwvc2ltcGxlVHlwZT4KCjxzaW1wbGVUeXBlIG5hbWU9
ImRhdGFUeXBlU2VtYW50aWNzIj4KICA8cmVzdHJpY3Rpb24gYmFzZT0ic3RyaW5nIj4KICAgIDxl
bnVtZXJhdGlvbiB2YWx1ZT0icXVhbnRpdHkiPgogICAgICA8YW5ub3RhdGlvbj4KICAgICAgICA8
ZG9jdW1lbnRhdGlvbj4KICAgICAgICAgIEEgcXVhbnRpdHkgdmFsdWUgcmVwcmVzZW50cyBhIGRp
c2NyZXRlIG1lYXN1cmVkIHZhbHVlIHBlcnRhaW5pbmcgdG8KICAgICAgICAgIHRoZSByZWNvcmQu
ICBUaGlzIGlzIGRpc3Rpbmd1aXNoZWQgZnJvbSBjb3VudGVycyB3aGljaCByZXByZXNlbnQgYW4K
ICAgICAgICAgIG9uZ29pbmcgbWVhc3VyZWQgdmFsdWUgd2hvc2UgIm9kb21ldGVyIiByZWFkaW5n
IGlzIGNhcHR1cmVkIGFzIHBhcnQKICAgICAgICAgIG9mIGEgZ2l2ZW4gcmVjb3JkLiAgSWYgbm8g
c2VtYW50aWMgcXVhbGlmaWVyIGlzIGdpdmVuLCB0aGUgaW50ZWdyYWwKICAgICAgICAgIGZpZWxk
cyBzaG91bGQgYmVoYXZlIGFzIGEgcXVhbnRpdHkuCiAgICAgICAgPC9kb2N1bWVudGF0aW9uPgog
ICAgICA8L2Fubm90YXRpb24+CiAgICA8L2VudW1lcmF0aW9uPgogICAgPGVudW1lcmF0aW9uIHZh
bHVlPSJjb3VudGVyIj4KICAgICAgPGFubm90YXRpb24+CiAgICAgICAgPGRvY3VtZW50YXRpb24+
CiAgICAgICAgICBBIG1lYXN1cmVtZW50IHdoaWNoIGlzIG9uZ29pbmcgZnJvbSB0aGUgcGVyc3Bl
Y3RpdmUgb2YgdGhlIGV4cG9ydGVyLgogICAgICAgICAgQmFzaWNhbGx5IHRoZSBzYW1lIHNlbWFu
dGljcyBhcyBjb3VudGVycyBpbiBTTk1QLiAgQ291bnRlcnMgYXJlCiAgICAgICAgICB1bnNpZ25l
ZCBhbmQgd3JhcCBiYWNrIHRvIHplcm8gYWZ0ZXIgcmVhY2hpbmcgdGhlIGxpbWl0IG9mIHRoZSB0
eXBlLgogICAgICAgICAgRS5nLiBhbiB1bnNpZ25lZDY0IHdpdGggY291bnRlciBzZW1hbnRpY3Mg
d2lsbCBjb250aW51ZSB0byBpbmNyZW1lbnQgdW50aWwKICAgICAgICAgIHJlYWNoaW5nIHRoZSB2
YWx1ZSBvZiAyKio2NCAtIDEuICBBdCB0aGlzIHBvaW50IHRoZSBuZXh0IGluY3JlbWVudAogICAg
ICAgICAgd2lsbCB3cmFwIGl0cyB2YWx1ZSB0byB6ZXJvIGFuZCBjb250aW51ZSBjb3VudGluZyBm
cm9tIHplcm8uCiAgICAgICAgPC9kb2N1bWVudGF0aW9uPgogICAgICA8L2Fubm90YXRpb24+CiAg
ICA8L2VudW1lcmF0aW9uPgogICAgPGVudW1lcmF0aW9uIHZhbHVlPSJpZGVudGlmaWVyIj4KICAg
ICAgPGFubm90YXRpb24+CiAgICAgICAgPGRvY3VtZW50YXRpb24+CiAgICAgICAgICBBbiBpbnRl
Z3JhbCB2YWx1ZSB3aGljaCBzZXJ2ZXMgYXMgYW4gaWRlbnRpZmllci4gIFNwZWNpZmljYWxseQog
ICAgICAgICAgbWF0aGVtYXRpY2FsIG9wZXJhdGlvbnMgb24gdHdvIGlkZW50aWZpZXJzIChhc2lk
ZSBmcm9tIHRoZSBlcXVhbGl0eQogICAgICAgICAgb3BlcmF0aW9uKSBhcmUgbWVhbmluZ2xlc3Mu
ICBFLmcuIEF1dG9ub21vdXMgU3lzdGVtIElkIDEgKiBBdXRvbm9tb3VzCiAgICAgICAgICBTeXN0
ZW0gSWQgMiBpcyBtZWFuaW5nbGVzcy4KICAgICAgICA8L2RvY3VtZW50YXRpb24+CiAgICAgIDwv
YW5ub3RhdGlvbj4KICAgIDwvZW51bWVyYXRpb24+CiAgICA8ZW51bWVyYXRpb24gdmFsdWU9ImZs
YWdzIj4KICAgICAgPGFubm90YXRpb24+CiAgICAgICAgPGRvY3VtZW50YXRpb24+CiAgICAgICAg
ICBBbiBpbnRlZ3JhbCB2YWx1ZSB3aGljaCBhY3R1YWxseSByZXByZXNlbnRzIGEgc2V0IG9mIGJp
dCBmaWVsZHMuCiAgICAgICAgICBMb2dpY2FsIG9wZXJhdGlvbnMgYXJlIGFwcHJvcHJpYXRlIG9u
IHN1Y2ggdmFsdWVzLCBidXQgbm90IG90aGVyCiAgICAgICAgICBtYXRoZW1hdGljYWwgb3BlcmF0
aW9ucy4gIEZsYWdzIHNob3VsZCBhbHdheXMgYmUgb2YgYW4gdW5zaWduZWQgdHlwZS4KICAgICAg
ICA8L2RvY3VtZW50YXRpb24+CiAgICAgIDwvYW5ub3RhdGlvbj4KICAgIDwvZW51bWVyYXRpb24+
CiAgPC9yZXN0cmljdGlvbj4KPC9zaW1wbGVUeXBlPgoKPHNpbXBsZVR5cGUgbmFtZT0iYXBwbGlj
YWJpbGl0eSI+CiAgPHJlc3RyaWN0aW9uIGJhc2U9InN0cmluZyI+CiAgICA8ZW51bWVyYXRpb24g
dmFsdWU9ImRhdGEiPgogICAgICA8YW5ub3RhdGlvbj4KICAgICAgICA8ZG9jdW1lbnRhdGlvbj4K
ICAgICAgICAgIFVzZWQgZm9yIGZpZWxkcyB0aGF0IGFyZSBhcHBsaWNhYmxlIHRvIGZsb3cgcmVj
b3JkcyBvbmx5LgogICAgICAgIDwvZG9jdW1lbnRhdGlvbj4KICAgICAgPC9hbm5vdGF0aW9uPgog
ICAgPC9lbnVtZXJhdGlvbj4KICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0ib3B0aW9uIj4KICAgICAg
PGFubm90YXRpb24+CiAgICAgICAgPGRvY3VtZW50YXRpb24+CiAgICAgICAgICBVc2VkIGZvciBm
aWVsZHMgdGhhdCBhcmUgYXBwbGljYWJsZSB0byBvcHRpb24gcmVjb3JkcyBvbmx5LgogICAgICAg
IDwvZG9jdW1lbnRhdGlvbj4KICAgICAgPC9hbm5vdGF0aW9uPgogICAgPC9lbnVtZXJhdGlvbj4K
ICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0iYWxsIj4KICAgICAgPGFubm90YXRpb24+CiAgICAgICAg
PGRvY3VtZW50YXRpb24+CiAgICAgICAgICBVc2VkIGZvciBmaWVsZHMgdGhhdCBhcmUgYXBwbGlj
YWJsZSB0byBmbG93IHJlY29yZHMgYXMgd2VsbAogICAgICAgICAgYXMgdG8gb3B0aW9uIHJlY29y
ZHMuCiAgICAgICAgPC9kb2N1bWVudGF0aW9uPgogICAgICA8L2Fubm90YXRpb24+CiAgICA8L2Vu
dW1lcmF0aW9uPgogIDwvcmVzdHJpY3Rpb24+Cjwvc2ltcGxlVHlwZT4KCjxzaW1wbGVUeXBlIG5h
bWU9InN0YXR1cyI+CiAgPHJlc3RyaWN0aW9uIGJhc2U9InN0cmluZyI+CiAgICA8ZW51bWVyYXRp
b24gdmFsdWU9ImN1cnJlbnQiPgogICAgICA8YW5ub3RhdGlvbj4KICAgICAgICA8ZG9jdW1lbnRh
dGlvbj4KICAgICAgICAgIEluZGljYXRlcyB0aGF0IHRoZSBmaWVsZCBkZWZpbml0aW9uIGlzIHRo
YXQgdGhlIGRlZmluaXRpb24KICAgICAgICAgIGlzIGN1cnJlbnQgYW5kIHZhbGlkLgogICAgICAg
IDwvZG9jdW1lbnRhdGlvbj4KICAgICAgPC9hbm5vdGF0aW9uPgogICAgPC9lbnVtZXJhdGlvbj4K
ICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0iZGVwcmVjYXRlZCI+CiAgICAgIDxhbm5vdGF0aW9uPgog
ICAgICAgIDxkb2N1bWVudGF0aW9uPgogICAgICAgICAgSW5kaWNhdGVzIHRoYXQgdGhlIGZpZWxk
IGRlZmluaXRpb24gaXMgb2Jzb2xldGUsIGJ1dAogICAgICAgICAgaXQgcGVybWl0cyBuZXcvY29u
dGludWVkIGltcGxlbWVudGF0aW9uIGluIG9yZGVyIHRvIGZvc3RlcgogICAgICAgICAgaW50ZXJv
cGVyYWJpbGl0eSB3aXRoIG9sZGVyL2V4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4KICAgICAgICA8
L2RvY3VtZW50YXRpb24+CiAgICAgIDwvYW5ub3RhdGlvbj4KICAgIDwvZW51bWVyYXRpb24+CiAg
ICA8ZW51bWVyYXRpb24gdmFsdWU9Im9ic29sZXRlIj4KICAgICAgPGFubm90YXRpb24+CiAgICAg
ICAgPGRvY3VtZW50YXRpb24+CiAgICAgICAgICBJbmRpY2F0ZXMgdGhhdCB0aGUgZmllbGQgZGVm
aW5pdGlvbiBpcyBvYnNvbGV0ZSBhbmQKICAgICAgICAgIHNob3VsZCBub3QgYmUgaW1wbGVtZW50
ZWQgYW5kL29yIGNhbiBiZSByZW1vdmVkIGlmCiAgICAgICAgICBwcmV2aW91c2x5IGltcGxlbWVu
dGVkLgogICAgICAgIDwvZG9jdW1lbnRhdGlvbj4KICAgICAgPC9hbm5vdGF0aW9uPgogICAgPC9l
bnVtZXJhdGlvbj4KICA8L3Jlc3RyaWN0aW9uPgo8L3NpbXBsZVR5cGU+Cgo8c2ltcGxlVHlwZSBu
YW1lPSJlbnVtUmFuZ2UiPgogIDxyZXN0cmljdGlvbiBiYXNlPSJzdHJpbmciLz4KPC9zaW1wbGVU
eXBlPgoKPHNpbXBsZVR5cGUgbmFtZT0iUmFuZ2UiPgogIDxyZXN0cmljdGlvbiBiYXNlPSJzdHJp
bmciLz4KPC9zaW1wbGVUeXBlPgoKPGVsZW1lbnQgbmFtZT0iZmllbGREZWZpbml0aW9ucyI+CiAg
PGNvbXBsZXhUeXBlPgogICAgPHNlcXVlbmNlPgogICAgICA8ZWxlbWVudCBuYW1lPSJmaWVsZCIg
bWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9InVuYm91bmRlZCI+CiAgICAgICAgPGNvbXBsZXhUeXBl
PgogICAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJkZXNjcmlw
dGlvbiIgdHlwZT0ic3RyaW5nIiBtaW5PY2N1cnM9IjEiIG1heE9jY3Vycz0iMSI+CiAgICAgICAg
ICAgICAgPGFubm90YXRpb24+CiAgICAgICAgICAgICAgICA8ZG9jdW1lbnRhdGlvbj4KICAgICAg
ICAgICAgICAgICAgVGhlIHNlbWFudGljcyBvZiB0aGlzIGluZm9ybWF0aW9uIGVsZW1lbnQuIERl
c2NyaWJlcwogICAgICAgICAgICAgICAgICBob3cgdGhpcyBmaWVsZCBpcyBkZXJpdmVkIGZyb20g
dGhlIGZsb3cgb3Igb3RoZXIgaW5mb3JtYXRpb24KICAgICAgICAgICAgICAgICAgYXZhaWxhYmxl
IHRvIHRoZSBvYnNlcnZlci4KICAgICAgICAgICAgICAgIDwvZG9jdW1lbnRhdGlvbj4KICAgICAg
ICAgICAgICA8L2Fubm90YXRpb24+CiAgICAgICAgICAgIDwvZWxlbWVudD4KICAgICAgICAgICAg
PGVsZW1lbnQgbmFtZT0idXNhZ2UiIHR5cGU9InN0cmluZyIgbWluT2NjdXJzPSIxIiBtYXhPY2N1
cnM9IjEiPgogICAgICAgICAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgICAgICAgICAgPGRvY3Vt
ZW50YXRpb24+CiAgICAgICAgICAgICAgICAgIHRvIGJlIGRvbmUgLi4uCiAgICAgICAgICAgICAg
ICA8L2RvY3VtZW50YXRpb24+CiAgICAgICAgICAgICAgPC9hbm5vdGF0aW9uPgogICAgICAgICAg
ICA8L2VsZW1lbnQ+CiAgICAgICAgICAgIDxlbGVtZW50IG5hbWU9InVuaXRzIiB0eXBlPSJzdHJp
bmciIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIj4KICAgICAgICAgICAgICA8YW5ub3RhdGlv
bj4KICAgICAgICAgICAgICAgIDxkb2N1bWVudGF0aW9uPgogICAgICAgICAgICAgICAgICBJZiB0
aGUgZmllbGQgaXMgYSBtZWFzdXJlIG9mIHNvbWUga2luZCwgdGhlIHVuaXRzIGlkZW50aWZ5CiAg
ICAgICAgICAgICAgICAgIHdoYXQgdGhlIG1lYXN1cmUgaXMuCiAgICAgICAgICAgICAgICA8L2Rv
Y3VtZW50YXRpb24+CiAgICAgICAgICAgICAgPC9hbm5vdGF0aW9uPgogICAgICAgICAgICA8L2Vs
ZW1lbnQ+CiAgICAgICAgICAgIDxlbGVtZW50IG5hbWU9InJlZmVyZW5jZSIgdHlwZT0ic3RyaW5n
IiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSI+CiAgICAgICAgICAgICAgPGFubm90YXRpb24+
CiAgICAgICAgICAgICAgICA8ZG9jdW1lbnRhdGlvbj4KICAgICAgICAgICAgICAgICAgSWRlbnRp
ZmllcyBhZGRpdGlvbmFsIHNwZWNpZmljYXRpb25zIHdoaWNoIG1vcmUgcHJlY2lzZWx5CiAgICAg
ICAgICAgICAgICAgIGRlZmluZSB0aGlzIGl0ZW0gb3IgcHJvdmlkZSBhZGRpdGlvbmFsIGNvbnRl
eHQgZm9yIGl0cyB1c2UuCiAgICAgICAgICAgICAgICA8L2RvY3VtZW50YXRpb24+CiAgICAgICAg
ICAgICAgPC9hbm5vdGF0aW9uPgogICAgICAgICAgICA8L2VsZW1lbnQ+CiAgICAgICAgICAgIDxl
bGVtZW50IG5hbWU9ImVudW1lcmF0ZWRSYW5nZSIgdHlwZT0iaXBmaXg6ZW51bVJhbmdlIiBtaW5P
Y2N1cnM9IjAiIG1heE9jY3Vycz0iMSI+CiAgICAgICAgICAgICAgPGFubm90YXRpb24+CiAgICAg
ICAgICAgICAgICA8ZG9jdW1lbnRhdGlvbj4KICAgICAgICAgICAgICAgICAgU29tZSBpdGVtcyBt
YXkgaGF2ZSBhIHNwZWNpZmljIHNldCBvZiBudW1lcmljCiAgICAgICAgICAgICAgICAgIGlkZW50
aWZpZXJzIGFzc29jaWF0ZWQgd2l0aCBhIHNldCBvZiBkaXNjcmV0ZSB2YWx1ZXMgdGhpcyBlbGVt
ZW50CiAgICAgICAgICAgICAgICAgIG1heSB0YWtlLiAgVGhlIG1lYW5pbmcgb2YgZWFjaCBkaXNj
cmV0ZSB2YWx1ZSBhbmQgYSBodW1hbiByZWFkYWJsZQogICAgICAgICAgICAgICAgICBuYW1lIHNo
b3VsZCBiZSBhc3NpZ25lZC4KICAgICAgICAgICAgICAgIDwvZG9jdW1lbnRhdGlvbj4KICAgICAg
ICAgICAgICA8L2Fubm90YXRpb24+CiAgICAgICAgICAgIDwvZWxlbWVudD4KICAgICAgICAgICAg
PGVsZW1lbnQgbmFtZT0iUmFuZ2UiIHR5cGU9ImlwZml4OlJhbmdlIiBtaW5PY2N1cnM9IjAiIG1h
eE9jY3Vycz0iMSI+CiAgICAgICAgICAgICAgPGFubm90YXRpb24+CiAgICAgICAgICAgICAgICA8
ZG9jdW1lbnRhdGlvbj4KICAgICAgICAgICAgICAgICAgU29tZSBlbGVtZW50cyBtYXkgb25seSBi
ZSBhYmxlIHRvIHRha2Ugb24gYSByZXN0cmljdGVkIHNldAogICAgICAgICAgICAgICAgICBvZiB2
YWx1ZXMgd2hpY2ggY2FuIGJlIGV4cHJlc3NlZCBhcyBhIHJhbmdlIChlLmcuIDAgdGhyb3VnaCA1
MTEKICAgICAgICAgICAgICAgICAgaW5jbHVzaXZlKS4gSWYgdGhpcyBpcyB0aGUgY2FzZSwgdGhl
IHZhbGlkIGluY2x1c2l2ZSByYW5nZSBzaG91bGQKICAgICAgICAgICAgICAgICAgYmUgc3BlY2lm
aWVkLgogICAgICAgICAgICAgICAgPC9kb2N1bWVudGF0aW9uPgogICAgICAgICAgICAgIDwvYW5u
b3RhdGlvbj4KICAgICAgICAgICAgPC9lbGVtZW50PgogICAgICAgICAgPC9zZXF1ZW5jZT4KICAg
ICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0ibmFtZSIgdHlwZT0ic3RyaW5nIiB1c2U9InJlcXVpcmVk
Ij4KICAgICAgICAgICAgPGFubm90YXRpb24+CiAgICAgICAgICAgICAgPGRvY3VtZW50YXRpb24+
CiAgICAgICAgICAgICAgICBBIHVuaXF1ZSBhbmQgbWVhbmluZ2Z1bCBuYW1lIGZvciB0aGUgZmll
bGQuIFRoZSBwcmVmZXJyZWQKICAgICAgICAgICAgICAgIHNwZWxsaW5nIGZvciB0aGUgbmFtZSBp
cyB0byB1c2UgbWl4ZWQgY2FzZSBpZiB0aGUgbmFtZSBpcwogICAgICAgICAgICAgICAgY29tcG91
bmQsIHdpdGggYW4gaW5pdGlhbCBsb3dlciBjYXNlIGxldHRlci4gKEUuZy4KICAgICAgICAgICAg
ICAgICJzb3VyY2VJcEFkZHJlc3MiKS4KICAgICAgICAgICAgICA8L2RvY3VtZW50YXRpb24+CiAg
ICAgICAgICAgIDwvYW5ub3RhdGlvbj4KICAgICAgICAgIDwvYXR0cmlidXRlPgogICAgICAgICAg
PGF0dHJpYnV0ZSBuYW1lPSJkYXRhVHlwZSIgdHlwZT0iaXBmaXg6ZGF0YVR5cGUiIHVzZT0icmVx
dWlyZWQiPgogICAgICAgICAgICA8YW5ub3RhdGlvbj4KICAgICAgICAgICAgICA8ZG9jdW1lbnRh
dGlvbj4KICAgICAgICAgICAgICAgIE9uZSBvZiB0aGUgdHlwZXMgbGlzdGVkIGluIHRoZSAiVHlw
ZSBTcGFjZSIgc2VjdGlvbi4KICAgICAgICAgICAgICAgIFRoZSB0eXBlIHNwYWNlIGZvciBhdHRy
aWJ1dGVzIGlzIGNvbnN0cmFpbmVkIHRvIGZhY2lsaXRhdGUKICAgICAgICAgICAgICAgIGltcGxl
bWVudGF0aW9uLiBUaGUgZXhpc3RpbmcgdHlwZSBzcGFjZSBkb2VzIGhvd2V2ZXIgZW5jb21wYXNz
CiAgICAgICAgICAgICAgICBtb3N0IGJhc2ljIHR5cGVzIHVzZWQgaW4gbW9kZXJuIHByb2dyYW1t
aW5nIGxhbmd1YWdlcywgYXMgd2VsbCBhcwogICAgICAgICAgICAgICAgc29tZSBkZXJpdmVkIHR5
cGVzIChzdWNoIGFzIElQQWRkcmVzcykgd2hpY2ggYXJlIGNvbW1vbiB0byB0aGlzCiAgICAgICAg
ICAgICAgICBkb21haW4gYW5kIHVzZWZ1bCB0byBkaXN0aW5ndWlzaC4KICAgICAgICAgICAgICA8
L2RvY3VtZW50YXRpb24+CiAgICAgICAgICAgIDwvYW5ub3RhdGlvbj4KICAgICAgICAgIDwvYXR0
cmlidXRlPgogICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSJkYXRhVHlwZVNlbWFudGljcyIgdHlw
ZT0iaXBmaXg6ZGF0YVR5cGVTZW1hbnRpY3MiIHVzZT0ib3B0aW9uYWwiPgogICAgICAgICAgICA8
YW5ub3RhdGlvbj4KICAgICAgICAgICAgICA8ZG9jdW1lbnRhdGlvbj4KICAgICAgICAgICAgICAg
IFRoZSBpbnRlZ3JhbCB0eXBlcyBtYXkgYmUgcXVhbGlmaWVkIGJ5IGFkZGl0aW9uYWwgc2VtYW50
aWMgZGV0YWlscy4KICAgICAgICAgICAgICAgIHF1YWxpZnlpbmcgdGhlIGZpZWxkcyBhcyAncXVh
bnRpdHknLCAnY291bnRlcicsICdpZGVudGlmaWVyJyBvciAnZmxhZ3MnLgogICAgICAgICAgICAg
IDwvZG9jdW1lbnRhdGlvbj4KICAgICAgICAgICAgPC9hbm5vdGF0aW9uPgogICAgICAgICAgPC9h
dHRyaWJ1dGU+CiAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9ImZpZWxkVHlwZSIgdHlwZT0ibm9u
TmVnYXRpdmVJbnRlZ2VyIiB1c2U9InJlcXVpcmVkIj4KICAgICAgICAgICAgPGFubm90YXRpb24+
CiAgICAgICAgICAgICAgPGRvY3VtZW50YXRpb24+CiAgICAgICAgICAgICAgICBBIG51bWVyaWMg
aWRlbnRpZmllciBhZG1pbmlzdGVyZWQgYnkgSUFOQS4gVGhpcyBpcyB1c2VkCiAgICAgICAgICAg
ICAgICBmb3IgY29tcGFjdCBpZGVudGlmaWNhdGlvbiBvZiBhbiBpbmZvcm1hdGlvbiBpdGVtIHdo
ZW4gZW5jb2RpbmcKICAgICAgICAgICAgICAgIHRlbXBsYXRlcyBpbiB0aGUgcHJvdG9jb2wuCiAg
ICAgICAgICAgICAgPC9kb2N1bWVudGF0aW9uPgogICAgICAgICAgICA8L2Fubm90YXRpb24+CiAg
ICAgICAgICA8L2F0dHJpYnV0ZT4KICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0idmVuZG9ySUQi
IHR5cGU9Im5vbk5lZ2F0aXZlSW50ZWdlciIgdXNlPSJvcHRpb25hbCI+CiAgICAgICAgICAgIDxh
bm5vdGF0aW9uPgogICAgICAgICAgICAgIDxkb2N1bWVudGF0aW9uPgogICAgICAgICAgICAgICAg
V2hlbiBleHRlbnNpb24gaXMgZG9uZSBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGUKICAgICAg
ICAgICAgICAgIElBTkEgSVBGSVggZmllbGRJZCByYW5nZSwgYSB2ZW5kb3JJZCBNVVNUIGJlIHBy
b3ZpZGVkLiAgVGhpcwogICAgICAgICAgICAgICAgaWRlbnRpZmllciBpcyBiYXNlZCBvbiBJQU5B
IGFzc2lnbmVkIGVudGVycHJpc2UgaWRlbnRpZmllcnMuCiAgICAgICAgICAgICAgPC9kb2N1bWVu
dGF0aW9uPgogICAgICAgICAgICA8L2Fubm90YXRpb24+CiAgICAgICAgICA8L2F0dHJpYnV0ZT4K
ICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0iYXBwbGljYWJpbGl0eSIgdHlwZT0iaXBmaXg6YXBw
bGljYWJpbGl0eSIgdXNlPSJyZXF1aXJlZCI+CiAgICAgICAgICAgIDxhbm5vdGF0aW9uPgogICAg
ICAgICAgICAgIDxkb2N1bWVudGF0aW9uPgogICAgICAgICAgICAgICAgdG8gYmUgZG9uZSAuLi4K
ICAgICAgICAgICAgICA8L2RvY3VtZW50YXRpb24+CiAgICAgICAgICAgIDwvYW5ub3RhdGlvbj4K
ICAgICAgICAgIDwvYXR0cmlidXRlPgogICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSJzdGF0dXMi
IHR5cGU9ImlwZml4OnN0YXR1cyIgdXNlPSJyZXF1aXJlZCI+CiAgICAgICAgICAgIDxhbm5vdGF0
aW9uPgogICAgICAgICAgICAgIDxkb2N1bWVudGF0aW9uPgogICAgICAgICAgICAgICAgdG8gYmUg
ZG9uZSAuLi4KICAgICAgICAgICAgICA8L2RvY3VtZW50YXRpb24+CiAgICAgICAgICAgIDwvYW5u
b3RhdGlvbj4KICAgICAgICAgIDwvYXR0cmlidXRlPgogICAgICAgIDwvY29tcGxleFR5cGU+CiAg
ICAgIDwvZWxlbWVudD4KICAgIDwvc2VxdWVuY2U+CiAgPC9jb21wbGV4VHlwZT4KCiAgPHVuaXF1
ZSBuYW1lPSJmaWVsZFR5cGVVbmlxdWUiPgogICAgPHNlbGVjdG9yIHhwYXRoPSJmaWVsZCIvPgog
ICAgPGZpZWxkIHhwYXRoPSJmaWVsZFR5cGUiLz4KICA8L3VuaXF1ZT4KPC9lbGVtZW50PgoKPC9z
Y2hlbWE+Cg==

--==========2147489275==========--


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 30 12:50:24 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03628
	for <ipfix-archive@lists.ietf.org>; Fri, 30 Jan 2004 12:50:24 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmcZc-0002gO-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jan 2004 11:36:56 -0600
Received: from ams-iport-1.cisco.com ([144.254.74.5])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmcZb-0002gH-00
	for ipfix@net.doit.wisc.edu; Fri, 30 Jan 2004 11:36:55 -0600
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 30 Jan 2004 18:37:34 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i0UHaUnu028441;
	Fri, 30 Jan 2004 18:36:31 +0100 (MET)
Received: from cisco.com (ams-clip-vpn-dhcp79.cisco.com [10.61.64.79])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA05727;
	Fri, 30 Jan 2004 17:36:51 GMT
Message-ID: <401A9632.7060909@cisco.com>
Date: Fri, 30 Jan 2004 17:36:50 +0000
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
CC: Juergen Quittek <quittek@ccrle.nec.de>, allison mankin <mankin@isi.edu>,
        ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: IPFIX requirements - security
References: <7D5D48D2CAA3D84C813F5B154F43B155028EC480@nl0006exch001u.nl.lucent.com>
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC480@nl0006exch001u.nl.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Bert
 >For example there is no point in providing greater
 >> confidentiality in the IPFIX protocol than exists at the
 >> observation point itself.
 >>

 >Is that true?
 >If the observation point is in a secure place, and the flow is
 >going to another secure place via a secure link, but you export
 >the data via an unsecure path to some collector, than that seems
 >incorrect to me.

But in that case the path has degraded the confidentially
of the observation point, and my point stands. I am concerned
with why you assert that we need to improve it.

>>Section 6.3.3 should therefore be reworded to something
>>of the following form:
>>
>>IPFIX data transferred from an exporting process to a
>>collecting process MUST NOT degrade the confidentiality of
>>the packet flows at the observation point.
>>
>>The method of transferring IPFIX data from the exporting
>>process to the collecting process MUST provide the level
>>of data integrity required by the collecting application.
>>
>>The authenticity of IPFIX data transferred from an exporting
>>process to a collecting process MUST be sufficient to meet
>>the application needs at the collector.
>>
> 
> I do not agree with the above.

I am sure that you do not support the converse, but you have
not justified the requirement to do better.

- Stewart


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 30 16:27:10 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18198
	for <ipfix-archive@lists.ietf.org>; Fri, 30 Jan 2004 16:27:10 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Amfqs-0001cI-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jan 2004 15:06:58 -0600
Received: from bay3-f35.bay3.hotmail.com ([65.54.169.35] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Amfqr-0001cD-00
	for ipfix@net.doit.wisc.edu; Fri, 30 Jan 2004 15:06:58 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 30 Jan 2004 13:06:57 -0800
Received: from 216.113.168.128 by by3fd.bay3.hotmail.msn.com with HTTP;
	Fri, 30 Jan 2004 21:06:56 GMT
X-Originating-IP: [216.113.168.128]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: quittek@ccrle.nec.de, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations
Date: Fri, 30 Jan 2004 13:06:56 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F35c3DzXDMBxY200002419@hotmail.com>
X-OriginalArrivalTime: 30 Jan 2004 21:06:57.0138 (UTC) FILETIME=[FEAB7D20:01C3E774]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Juergen,

  Thanks for continuing the dialog, hopefully it will help flesh out the 
issues (or misperceptions).

  More comments inline...

-- Jeff


>From: Juergen Quittek <quittek@ccrle.nec.de>
>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA 
>considerations
>Date: Fri, 30 Jan 2004 13:59:10 +0100
>
>Jeff,
>
>--On 29.01.2004 10:20 Uhr -0800 Jeff Meyer wrote:
>
>>Juergen,
>>
>>   XML-Schema can be thought of as a pure Informaiton Model.
>
>Of course we can say:
>  "Here is a combined info and data model, please ignore the data model 
>part,
>   because this standard is just about the info model."
>
>But this appears to be - at least - curious.

Well, the authors of XML-Schema had XML documents in mind, so XML-Schema 
does address both in a single document.  That is a bit unfortunate as it 
does cause this confusion.

Carrying the ASN.1 analogy, the ASN.1 authors separated the modeling and 
encoding.  Initially they only had one encoding document, BER, but over time 
have created others.

IPDR and IPFIX-protocol are defining additional encodings from the same 
XML-Schema model.

>
>>XML-Schema and XML also define productions which can be used to create
>>instance documents which are a data model and encoded in ASCII.
>
>This is what people call a data model.

Yup, (or encoding model).  So we're in agreement here.

>
>>IPDR takes full advantage of this by providing both
>>ASCII and Binary encodings from the same information model.
>>I.e. XML-Schema CAN be used AS IS as a pure information model.
>
>Yes and we can have exactly the same with what I suggested.
>The current version of the IPFIX INFO model does not contain
>a binary encoding, but it does contain an ASCII encoding.

No.  IPFIX-info uses XML-Schema as an information model.  XML-Schema authors 
defined a specific encoding which is ASCII based, and as stated above, they 
didn't separate it from the encoding (data model).  IPFIX-protocol defines a 
binary model.  IPDR defines another binary data model which is equivalent to 
the ASCII model from XML-Schema (assuming the subset of XML-Schema defined 
in appendix A.4 of IPDR is followed).

>
>>   Think of ASN.1 which has a Syntax and various encoding rules such
>>as BER, DER and others (even an XER).  At some point you need to
>>formally define something, but that DOES NOT mean that the ASN.1
>>syntax is just a BINARY encoding model nor is it just
>>one encoding model.  Hence it IS separate from encoding.
>>
>>   I view XML-Schema as the ASN.1 of the 21st century, only with a
>>much richer set of off the shelf and often free tools and other
>>interoperable components.
>
>I am sure you do not claim to inherit all properties of ASN.1 ;-)

Nope, just the useful stuff ;-)

>
>>   Renaming things which are well defined (e.g. int) to duplicate
>>names (e.g. ipfix-int) is just a lot of unnecessary rework.
>>The temptation to simply redefine things is often large for
>>engineers.  However in the long run reusing existing work
>>increases the likelihood that people will converge on certain
>>key patterns.
>
>It is not just renaming.  It is replacing the concrete XML data type
>with an abstract one that can be mapped to XML as well as to many other
>domains.

The data types in XML-Schema can be thought of as abstract.  Let's look at a 
concrete example from XML-Schema Part-2 Datatypes 
(http://www.w3.org/TR/xmlschema-2/#long)

3.3.16 long
[Definition:]   long is ·derived· from integer by setting the value of 
·maxInclusive· to be 9223372036854775807 and ·minInclusive· to be 
-9223372036854775808. The ·base type· of long is integer.

3.3.16.1 Lexical representation
long has a lexical representation consisting of an optional sign followed by 
a finite-length sequence of decimal digits (#x30-#x39). If the sign is 
omitted, "+" is assumed. For example: -1, 0, 12678967543233, +100000.

3.3.16.2 Canonical representation
The canonical representation for long is defined by prohibiting certain 
options from the Lexical representation (§3.3.16.1). Specifically, the the 
optional "+" sign is prohibited and leading zeroes are prohibited.


The "Definition" I would consider abstract.  The subsections "Lexical rep" 
and "Cannonical rep" mix in the concerns of ASCII encoding, which we can 
ignore for IPFIX purposes.


>And if you look at other INFO models, for example defined
>in CIM by the DMTF, always abstract data types are used in info models.

Yeah, and these various specs all calls the same basic concept something 
different.  Big help that is!  I would refer to this as the "Tower of Babel" 
approach.

>Concrete ones are just used in data models.
>
>But even if you just consider it as renaming, it solves some problems.
>  [And having worked as software engineer, I know that renaming (e.g. by
>   endless sets of #DEFINEs in C and C++ is not really unusual.]

Are you saying this is a good thing?   I know one reason this is used is 
because of the ambiguity in the C language around what an "int" is.  Is it a 
32-bit integer or whatever is basic to the architecture (e.g. 16-bit or 
64-bit).  This ambiguity started the ball rolling as developers wanted to 
ensure that there was a single name for data types of a specific range of 
values.

Our model doesn't introduce that ambiguity, hence (at least part of) the 
reason for using such #defines (i.e. making up new names) is not necessary.

>The problems we can solve are
>
>  1. We can replace 'hexBinary' by 'octetArray' or something else.
>     Why should a binary data type use 'hex' in its name, if not ONLY
>     with respect to its ASCII data encoding?  And the encoding that really
>     is of importance for IPFIX standardization is the binary encoding
>     by the protocol.

Well the name reflects the initial focus of XML-Schema authors on ASCII 
encoding.  I would prefer "octetArray", but I also have an aversion to 
inventing new names for semantically equivalent things.

This is probably the worst example of mixing in concerns.

The other item I see this coming up in is dateTime.  The definition is 
ambiguous in terms of precision because they allow any valid ISO style time 
string, i.e. arbitrary precision.  They can get away with this because it is 
ASCII encoded.

For the basic types int, long, unsigned short...  I see no issue.

For these two I think clarifying their application in the IPFIX information 
model is sufficient.

>
>  2. We do not have to refer to an IPDR document as a normative reference.
>     This has three implications:
>
>     First, I do not know if this is (so far) possible at all for IETF
>     standard track documents.

First time I heard this.

>
>     Second, I am not sure if the IPDR definition of IPv4 addresses and 
>IPv6
>     addresses is what the IETF would like to use.  It does not make sense
>     to import IPv4 address XML encoding from the IPDR definitions in one
>     IETF standard and to use another source in another IETF standard.


Well, this was not the indication I got from Andrew Norton who has been 
involved in the application of XML w/in IETF (see bottom of this thread).  
I.e. he seemed in favor of reducing the "Tower of Babel".

>
>     Third, if we use our own ABSTRACT data types, users can more easily
>     choose other XML encodings than the one promoted by IPDR.
>     [Nothing against IPDR. I like it very much and my company is a member]
>     Management systems and database builders/integrators may/will already
>     have their own (XML) data types for flow recording. If we use an
>     abstract data type we do not explicitly request them to use the
>     IPDR definitions.

I don't quite follow this.  There are 20 or so types defined, 15 or so names 
come directly from XML-Schema base types.  The remainder address types which 
are important from an IPFIX perspective.

For serialization, users are not required to use IPDR XML or Binary, 
especially if they enjoy spending money on needless reinvention.

For instance since the Schema defines basic fields, the user is free to 
create an alternate enclosing complexType and put any other informaiton they 
like into it.  Now if they want to rename the fields themselves, that is 
more work (e.g. calling "flowCreationTime" "startTime" instead).  However, 
any form of information model wouldn't really help in that low level of 
renaming.


>
>
>    Juergen
>
>>-- Jeff
>>
>>
>>>From: Juergen Quittek <quittek@ccrle.nec.de>
>>>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>>>Subject: Re: [ipfix] [issue] INFO-29  Namespace definitions may need IANA
>>>considerations
>>>Date: Thu, 29 Jan 2004 13:31:19 +0100
>>>
>>>Jeff,
>>>
>>>I suggest to follow a completely different way of solving this
>>>problems such that everybody get what is needed.
>>>
>>>I see the cause in our dispute that the Appendix of the INFO model
>>>document is NOT just an information model, but a data model.
>>>
>>>As you argued well some time ago, it is a bad idea specifying
>>>binary encodings in the info model document, because this would
>>>already be a data model, which may vary among different protocols
>>>that potentially use the IPFIX INFO model.
>>>
>>>So, it is completely correct, that the binary encoding has become
>>>a part of the IPFIX PROTOCOL document.  But still the IPFIX INFO
>>>model document contains a data model: the XML ASCII encoding for
>>>each information element. This is a data model. IMHO this is wrong!
>>>
>>>We should follow a clean approach by just specifying an
>>>information model.  This would solve several of the open issues
>>>we are discussing, including the name space problem (iprd:),
>>>because we get completely independent of these data encoding issues
>>>and still can support IPDR data types in XML-based applications.
>>>
>>>Here is my suggestion:
>>>
>>>Currently, the Appendix is an XML schema defining which fixes ASCII
>>>encodings for each information element.  I suggest to replace this
>>>XML schema by an XML document.  The document would consist of a set
>>>of XML element, each of them specifying a single information elements
>>>with a set of attributes and/or contained XML elements exactly
>>>covering all properties of information elements as defined in section 3.
>>>(We can use a small, simple XML schema for checking consistency of this
>>>XML document.)
>>>
>>>Information elements defined this way would not have a standard XML,
>>>IPDR, or other data type (data model should be separated from info 
>>>model),
>>>but would be defined just by English text, for example
>>>  ipfix-int: integer value in the range of -2147483648 to 2147483647
>>>  ipfix-dateTime: number of seconds since Jan 1st, 1970, 00:00 h
>>>  ipfix-ipv4address: integral representation of a 32 bit IPv4 address
>>>  ...
>>>We would create our own IPFIX type space for the information elements.
>>>
>>>Based on this pure information model, we can use XSLT (as we do it now)
>>>to generate all the text in Section 6 describing the information 
>>>elements.
>>>
>>>Now, if you want to realize an XML-based application, you can take the
>>>new XML document and use XSLT for automatic generation of a schema, such
>>>as the one we have in the Appendix of the current version of the INFO 
>>>model
>>>document.  You see, you still have all the advantages of the machine-
>>>readability and all opportunities to generate IPFIX XML parsers
>>>automatically.
>>>But with the suggested change you would also have a clean information 
>>>model
>>>in the IPFIX INFO document avoiding all discussions on whether or not to
>>>use the IPDR data types.
>>>
>>>I am currently working together with Thomas, editor of the PSAMP INFO
>>>model, to implement the idea sketched above. We will send an example to
>>>this list in a few days.
>>>
>>>Regards,
>>>
>>>    Juergen
>>>
>>>
>>>--On 27.01.2004 23:55 h -0800 Jeff Meyer wrote:
>>>
>>>>The current info-model-02 specification contains references to XML type
>>>>names and semantics borrowed directly from the XML-Schema specification 
>>>>as
>>>>well as extensions.
>>>>
>>>>Currently these extensions borrow from existing work of IPDR as well as
>>>>newly identified types currently specific to IPFIX.
>>>>
>>>>There are a few ways to address this.
>>>>
>>>>The following e-mail thread discusses the options and opinion of this
>>>>editor as well as opinions from Andrew Norton who is involved in IETF's
>>>>and IANA's work in utilizing XML in RFC's.
>>>>
>>>>
>>>>Jeff,
>>>>
>>>>It would seem that this is all a matter of "taste" as any of these 
>>>>options
>>>>technically work.  Personally I would go with option 3; though it 
>>>>requires
>>>>more coordination between organizations, to an outsider it would seem 
>>>>more
>>>>cohesive.
>>>>
>>>>There is a practical difference between option 1 and option 3 in terms 
>>>>of
>>>>setting the standard.  With option 3, if IPDR upgrades their standard, 
>>>>the
>>>>IPFIX group needs to do nothing to incorporate the changes.  However, 
>>>>with
>>>>option 1, IPFIX will have to
>>>>standardize a new schema and issue new RFC's.
>>>>
>>>>-andy
>>>>
>>>>Jeff Meyer wrote:
>>>>     Hi Andy,
>>>>
>>>>I wanted to get your opinion on extending the XML-Schema type system for
>>>>some specific information modeling requirements encountered by the IPFIX
>>>>working group.
>>>>
>>>>IPFIX currently reuses about 15 types from XML-Schema directly, however
>>>>there are several types which are worthwile to distinguish from an IPFIX
>>>>persepective which are not defined by XML-Schema.
>>>>
>>>>These include types to identify timestamps of specific resolution (e.g.
>>>>mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and one 
>>>>for
>>>>UUIDs.
>>>>
>>>>Today most of these extension types are defined in the public NDM-U 
>>>>3.1.1
>>>>specification from the industry consortium called IPDR.org.  There are a
>>>>couple which are not are related to the high resolution timestamps (uSec
>>>>and nSec).
>>>>
>>>>The NDM-U 3.1.1 specificaiton is avaiable at
>>>>http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically section
>>>>A.4.4.
>>>>
>>>>The IPFIX-Info reference is available at:
>>>>
>>>>http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#anchor4
>>>>
>>>>
>>>>This is a link to the specific secion in the HTML format of the info 
>>>>model
>>>>based on RFC2629.
>>>>
>>>>
>>>>The quesion at hand is whether to follow one of the following 3 options:
>>>>
>>>>    1. have a single XML-Schema which defines the extension types 
>>>>relevant
>>>>to IPFIX and contained in the IPFIX namespace
>>>>    2. reference the existing types targeted by IPDR and add only the 
>>>>new
>>>>types specific to the IPFIX Schema
>>>>    3. petition IPDR to define the remaining two IPFIX types for
>>>>timestamps in their upcoming 3.5 specification (likely timeframe Feb. or
>>>>March)
>>>>
>>>>I get the impression from IPFIX discussions that referencing IPDR is
>>>>something that some vocal participants find objectionable, i.e. they 
>>>>would
>>>>prefer to see option 1.
>>>>
>>>>My personal preference would be to go with option 3 or 2.  I believe 3 
>>>>is
>>>>doable and would reduce the number of places where people have to look 
>>>>for
>>>>things.  Option 1 I see as creating some confusion in the space, but
>>>>ultimately addressable through XSL
>>>>or other mapping functions, if that's what it takes to get consensus.
>>>>
>>>>
>>>>Any guidance on your part would be appreciated.
>>>>
>>>>Regards,
>>>>
>>>>Jeff Meyer
>>>>
>>>>_________________________________________________________________
>>>>Get a FREE online virus check for your PC here, from McAfee.
>>>>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>>>>
>>>>
>>>>--
>>>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>>>body
>>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>"unsubscribe ipfix" in message body
>>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>>
>>>
>>
>>_________________________________________________________________
>>Find high-speed ‘net deals ? comparison-shop your local providers here. 
>>https://broadband.msn.com
>>
>
>
>
>

_________________________________________________________________
What are the 5 hot job markets for 2004? Click here to find out. 
http://msn.careerbuilder.com/Custom/MSN/CareerAdvice/WPI_WhereWillWeFindJobsIn2004.htm?siteid=CBMSN3006&sc_extcmp=JS_wi08_dec03_hotmail1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 30 16:35:42 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18688
	for <ipfix-archive@lists.ietf.org>; Fri, 30 Jan 2004 16:35:42 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Amfub-0001xP-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jan 2004 15:10:49 -0600
Received: from bay3-f32.bay3.hotmail.com ([65.54.169.32] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Amfua-0001xH-00
	for ipfix@net.doit.wisc.edu; Fri, 30 Jan 2004 15:10:48 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 30 Jan 2004 13:10:47 -0800
Received: from 216.113.168.128 by by3fd.bay3.hotmail.msn.com with HTTP;
	Fri, 30 Jan 2004 21:10:47 GMT
X-Originating-IP: [216.113.168.128]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: Thomas.Dietz@netlab.nec.de, quittek@ccrle.nec.de, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-25 Options data is not addressed in info-model
Date: Fri, 30 Jan 2004 13:10:47 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F32jon60TMZQu500002420@hotmail.com>
X-OriginalArrivalTime: 30 Jan 2004 21:10:47.0855 (UTC) FILETIME=[88301BF0:01C3E775]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Thomas,

  Thanks for the clarification on Usage.

  In your statement, "Juergen is working on an improved version of XML," any 
details here?  E.g. is there an interest to use <attribute> vs. <element> to 
get more compact XML?

  I'm not sure you gain a whole lot in this approach.  Simply moving to the 
equivalent binary encoding form from IPDR is going to get you a much bigger 
bang for the buck than tweaking the XML.

-- Jeff


>From: Thomas Dietz <Thomas.Dietz@netlab.nec.de>
>To: Jeff Meyer <inetpix@msn.com>, quittek@ccrle.nec.de,        
>ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-25 Options data is not addressed in 
>info-model
>Date: Fri, 30 Jan 2004 14:53:32 +0100
>
>Jeff,
>
>The "Usage" field was meant a little bit different than description and
>applicability. The description just says what it is (an IP address, a
>packet counter for lost packets or a parameter within a sampling method
>in PSAMP), the applicability states if the field can be used by the
>data flowset the option flowset or both and finally the usage says in
>which context the field is meaningful. Maybe usage is more important
>in the PSAMP info model than in the IPFIX one. Let me give you an example:
>
>We currently have defined an "intervalTime" field in the PSAMP info model.
>The description says that it is the time between two samples. The
>applicability says it is used in the option flowset. Finally the usage says
>that it is an option for the Systematic Time Based sampling.
>
>Regarding section 7 in PSAMP you are missing the XML Document. Actually
>there is such a document and we create section 6 from this document using
>XSLT like you did. In the current state we were not to sure if we should
>include the XML document into the draft. This is still to be discussed
>on the PSAMP mailing list.
>
>Furthermore, as Juergen already posted on the IPFIX mailing list, we
>are working together on an improved version of this XML encoding.
>
>Regards,
>
>Thomas
>
>--On Donnerstag, Januar 29, 2004 10:11:47 -0800 Jeff Meyer 
><inetpix@msn.com> wrote:
>
>>Juergen,
>>
>>   I see two separate issues:
>>
>>    1. Adding an applicability statement to the set of information 
>>captured
>>for each attribute.  Sounds like a good idea to me.  (should be [issue]
>>INFO-31)
>>
>>    2. Segregating per flow information from exporter general information
>>(i.e. Option Templates).
>>
>>   I'd like to do both.
>>
>>   I also notice in PSAMP that there is yet another field called "Usage", 
>>in
>>scanning the text, it would appear to me that this typically is just a
>>rewording of the "Description" and "Applicability" fields.  So I would
>>question whether it is needed.
>>
>>   Finally, I see there is text around XML in a section 7 in PSAMP, but no
>>actual XML doc.  Did the group ever create an XML-Schema?  Or did they 
>>fill
>>in the text based "template" from section 6?
>>
>>-- Jeff
>>
>>
>>>From: Juergen Quittek <quittek@ccrle.nec.de>
>>>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>>>Subject: Re: [ipfix] [issue] INFO-25  Options data is not addressed in
>>>info-model
>>>Date: Thu, 29 Jan 2004 12:37:09 +0100
>>>
>>>Jeff,
>>>
>>>I agree.  In the PSAMP INFO model <draft-ietf-psamp-info-00.txt>
>>>there is already an additional entry in the list of properties of
>>>en information elements to be specified for each element:
>>>
>>>    Applicability - a statement in which flow records the attribute is
>>>      used. An attribute can be exported in a data flow record, a
>>>      options data flow record or both.
>>>
>>>We should add this property also to the IPFIX INFO model to be stated
>>>for each info element.
>>>
>>>    Juergen
>>>
>>>
>>>--On 26.01.2004 23:19 Uhr -0800 Jeff Meyer wrote:
>>>
>>>>Currently the content of the information model deals with information
>>>>elements related
>>>>to a single flow (or possibly aggregated set of flows).
>>>>
>>>>There is another class of information which pertains to details about 
>>>>the
>>>>exporter itself.
>>>>(e.g. total number of flows exported, drops and other items).  Some of
>>>>these are
>>>>currently described in the protocol draft under the discussion of 
>>>>"Option
>>>>Templates".
>>>>
>>>>These information elements should be described in the information model
>>>>as  well. Probably
>>>>in a separate section dealing with "Exporter Detail Information".
>>>>
>>>>-- Jeff Meyer
>>>>
>>>>_________________________________________________________________
>>>>Get a FREE online virus check for your PC here, from McAfee.
>>>>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>>>>
>>>>
>>>>--
>>>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>>>body
>>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>"unsubscribe ipfix" in message body
>>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>
>>>
>>>
>>>
>>>
>>>--
>>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>>body
>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>"unsubscribe ipfix" in message body
>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>
>>_________________________________________________________________
>>Check out the new MSN 9 Dial-up — fast & reliable Internet access with
>>prime features! http://join.msn.com/?pgmarket=en-us&page=dialup/home&ST=1
>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>

_________________________________________________________________
Scope out the new MSN Plus Internet Software — optimizes dial-up to the max! 
   http://join.msn.com/?pgmarket=en-us&page=byoa/plus&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 30 16:44:50 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21117
	for <ipfix-archive@lists.ietf.org>; Fri, 30 Jan 2004 16:44:50 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmgJg-0002Yg-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jan 2004 15:36:44 -0600
Received: from bay3-f7.bay3.hotmail.com ([65.54.169.7] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmgJf-0002Ya-00
	for ipfix@net.doit.wisc.edu; Fri, 30 Jan 2004 15:36:43 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 30 Jan 2004 13:36:42 -0800
Received: from 216.113.168.128 by by3fd.bay3.hotmail.msn.com with HTTP;
	Fri, 30 Jan 2004 21:36:42 GMT
X-Originating-IP: [216.113.168.128]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: quittek@ccrle.nec.de, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations
Date: Fri, 30 Jan 2004 13:36:42 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F7dvdl1eCsgTG9000025df@hotmail.com>
X-OriginalArrivalTime: 30 Jan 2004 21:36:42.0949 (UTC) FILETIME=[27189F50:01C3E779]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Juergen,

  Some interesting work.  I like some of the elements.

  Comments inline.

-- Jeff


>From: Juergen Quittek <quittek@ccrle.nec.de>
>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA 
>considerations
>Date: Fri, 30 Jan 2004 17:32:52 +0100
>
>Jeff and all,
>
>Here is an alternative suggestion for the XML representation of the
>info model that I developed together with Thomas, one of the editors of
>the PSAMP info model.  This XML representation of the info model uses
>an XML document (ipfix.xml) instead of an XML schema for specifying
>the IPFIX information elements (or fields as the IPFIX protocol document
>calls them).

Do you have XSL templates to go to/from this format to the more generally 
useful XML-Schema syntax?

>It just shows the first 11 elements defined in the current draft,
>but this is enough to show how this XML format looks like.
>
>File ipfix.xml can be used for automatically generating Section 6 of
>the INFO model document as well as the XML schema used for the previous
>version.

Do you have that XSL template available publicly?

>The difference is that it uses abstract data types (as a data
>model should) instead of concrete ones.

How are these any more abstract?  Your ipfix.xsd in turn derives these shiny 
new names from existing XML Schema Types.  In other words new names, same 
thing.

>
>In addition, file ipfix.xsd contains an XML schema, that can be used
>for validating the ipfix.xml file. It defines the properties of fields/
>information elements that are used in ipfix.xml and it also includes
>a definition of the abstract data types used in ipfix.xml.

So, one thing this does is provide validation that required annotations are 
present.  That could be useful.

What you have lost is the ability to validate or have an XML format of the 
information simply fall out of the work.  This could be mitigated if you 
have the XML-Schema -> ipfix.xml XSL, do you have this?

>
>A nice consequence is that now not just Section 6 (field definitions)
>but also Section 3 (Properties of an IPFIX Flow Attribute) and Section 4
>(Type Space) can be generated out of XML input.

This is interesting and potentially useful, with the exception of creating 
new names for lots of existing types.

One benefit I see is that it would constrain and allow validation that only 
allowed types are present in this style information model.  Reusing well 
defined names from XML-Schema Types would obviously be my preference.

>
>While section 6 is generated from ipfix.xml, Sections 3 and 4 are
>generated from ipfix.xsd.

Do you have the XSL for this?

>
>Also the XML schema, we used for the previous versions of the INFO model
>can be generated out of the info model given in ipfix.xml.  You just have
>to define a mapping of the used abstract data types to concrete ones,
>such as the IPDR definitions of IPv4 and IPv6 addresses.

OK, nice.

>
>Conclusion:
>- This version is a pure data model using abstract data types and without
>  any data encodings.

Umm, you mean "pure information model"?

I would say "This version is enables the validation of IPFIX information 
models using off the shelf tools" and enforces restrictions which are not 
assigned in the technique of using XML-Schema directly as an information 
model."

>- It does not have dependencies on external data type definitions by IPDR.

Thank god for that!

>- We do not loose anything, because the XML schema, we used so far
>  (including XML data types) can be generated automatically.

If you have any of the XSL's I'd appreciate your making them public.  
Ultimately having a direct representation in XML-Schema is useful for 
validating instance documents which contain sets of data serialized in this 
format, for use of IPDR's XML and XDR serialization tools and other things.

So, in general, I agree there are some benefits which you've identified.  As 
long as it doesn't take away other existing benefits, i.e. immediate 
mechanisms for serialization in XML and binary formats with open source 
tools.  Having bi directional XSL info-model.xml <-> info-model.xsd would be 
good.

>
>Cheers,
>
>    Juergen
>
>--On 30.01.2004 13:59 Uhr +0100 Juergen Quittek wrote:
>
>>Jeff,
>>
>>--On 29.01.2004 10:20 Uhr -0800 Jeff Meyer wrote:
>>
>>>Juergen,
>>>
>>>   XML-Schema can be thought of as a pure Informaiton Model.
>>
>>Of course we can say:
>>   "Here is a combined info and data model, please ignore the data model 
>>part,
>>    because this standard is just about the info model."
>>
>>But this appears to be - at least - curious.
>>
>>>XML-Schema and XML also define productions which can be used to create
>>>instance documents which are a data model and encoded in ASCII.
>>
>>This is what people call a data model.
>>
>>>IPDR takes full advantage of this by providing both
>>>ASCII and Binary encodings from the same information model.
>>>I.e. XML-Schema CAN be used AS IS as a pure information model.
>>
>>Yes and we can have exactly the same with what I suggested.
>>The current version of the IPFIX INFO model does not contain
>>a binary encoding, but it does contain an ASCII encoding.
>>
>>>   Think of ASN.1 which has a Syntax and various encoding rules such
>>>as BER, DER and others (even an XER).  At some point you need to
>>>formally define something, but that DOES NOT mean that the ASN.1
>>>syntax is just a BINARY encoding model nor is it just
>>>one encoding model.  Hence it IS separate from encoding.
>>>
>>>   I view XML-Schema as the ASN.1 of the 21st century, only with a
>>>much richer set of off the shelf and often free tools and other
>>>interoperable components.
>>
>>I am sure you do not claim to inherit all properties of ASN.1 ;-)
>>
>>>   Renaming things which are well defined (e.g. int) to duplicate
>>>names (e.g. ipfix-int) is just a lot of unnecessary rework.
>>>The temptation to simply redefine things is often large for
>>>engineers.  However in the long run reusing existing work
>>>increases the likelihood that people will converge on certain
>>>key patterns.
>>
>>It is not just renaming.  It is replacing the concrete XML data type
>>with an abstract one that can be mapped to XML as well as to many other
>>domains.  And if you look at other INFO models, for example defined
>>in CIM by the DMTF, always abstract data types are used in info models.
>>Concrete ones are just used in data models.
>>
>>But even if you just consider it as renaming, it solves some problems.
>>   [And having worked as software engineer, I know that renaming (e.g. by
>>    endless sets of #DEFINEs in C and C++ is not really unusual.]
>>The problems we can solve are
>>
>>   1. We can replace 'hexBinary' by 'octetArray' or something else.
>>      Why should a binary data type use 'hex' in its name, if not ONLY
>>      with respect to its ASCII data encoding?  And the encoding that 
>>really
>>      is of importance for IPFIX standardization is the binary encoding
>>      by the protocol.
>>
>>   2. We do not have to refer to an IPDR document as a normative 
>>reference.
>>      This has three implications:
>>
>>      First, I do not know if this is (so far) possible at all for IETF
>>      standard track documents.
>>
>>      Second, I am not sure if the IPDR definition of IPv4 addresses and 
>>IPv6
>>      addresses is what the IETF would like to use.  It does not make 
>>sense
>>      to import IPv4 address XML encoding from the IPDR definitions in one
>>      IETF standard and to use another source in another IETF standard.
>>
>>      Third, if we use our own ABSTRACT data types, users can more easily
>>      choose other XML encodings than the one promoted by IPDR.
>>      [Nothing against IPDR. I like it very much and my company is a 
>>member]
>>      Management systems and database builders/integrators may/will 
>>already
>>      have their own (XML) data types for flow recording. If we use an
>>      abstract data type we do not explicitly request them to use the
>>      IPDR definitions.
>>
>>
>>     Juergen
>>
>>>-- Jeff
>>>
>>>
>>>>From: Juergen Quittek <quittek@ccrle.nec.de>
>>>>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>>>>Subject: Re: [ipfix] [issue] INFO-29  Namespace definitions may need 
>>>>IANA
>>>>considerations
>>>>Date: Thu, 29 Jan 2004 13:31:19 +0100
>>>>
>>>>Jeff,
>>>>
>>>>I suggest to follow a completely different way of solving this
>>>>problems such that everybody get what is needed.
>>>>
>>>>I see the cause in our dispute that the Appendix of the INFO model
>>>>document is NOT just an information model, but a data model.
>>>>
>>>>As you argued well some time ago, it is a bad idea specifying
>>>>binary encodings in the info model document, because this would
>>>>already be a data model, which may vary among different protocols
>>>>that potentially use the IPFIX INFO model.
>>>>
>>>>So, it is completely correct, that the binary encoding has become
>>>>a part of the IPFIX PROTOCOL document.  But still the IPFIX INFO
>>>>model document contains a data model: the XML ASCII encoding for
>>>>each information element. This is a data model. IMHO this is wrong!
>>>>
>>>>We should follow a clean approach by just specifying an
>>>>information model.  This would solve several of the open issues
>>>>we are discussing, including the name space problem (iprd:),
>>>>because we get completely independent of these data encoding issues
>>>>and still can support IPDR data types in XML-based applications.
>>>>
>>>>Here is my suggestion:
>>>>
>>>>Currently, the Appendix is an XML schema defining which fixes ASCII
>>>>encodings for each information element.  I suggest to replace this
>>>>XML schema by an XML document.  The document would consist of a set
>>>>of XML element, each of them specifying a single information elements
>>>>with a set of attributes and/or contained XML elements exactly
>>>>covering all properties of information elements as defined in section 3.
>>>>(We can use a small, simple XML schema for checking consistency of this
>>>>XML document.)
>>>>
>>>>Information elements defined this way would not have a standard XML,
>>>>IPDR, or other data type (data model should be separated from info 
>>>>model),
>>>>but would be defined just by English text, for example
>>>>  ipfix-int: integer value in the range of -2147483648 to 2147483647
>>>>  ipfix-dateTime: number of seconds since Jan 1st, 1970, 00:00 h
>>>>  ipfix-ipv4address: integral representation of a 32 bit IPv4 address
>>>>  ...
>>>>We would create our own IPFIX type space for the information elements.
>>>>
>>>>Based on this pure information model, we can use XSLT (as we do it now)
>>>>to generate all the text in Section 6 describing the information 
>>>>elements.
>>>>
>>>>Now, if you want to realize an XML-based application, you can take the
>>>>new XML document and use XSLT for automatic generation of a schema, such
>>>>as the one we have in the Appendix of the current version of the INFO 
>>>>model
>>>>document.  You see, you still have all the advantages of the machine-
>>>>readability and all opportunities to generate IPFIX XML parsers
>>>>automatically.
>>>>But with the suggested change you would also have a clean information 
>>>>model
>>>>in the IPFIX INFO document avoiding all discussions on whether or not to
>>>>use the IPDR data types.
>>>>
>>>>I am currently working together with Thomas, editor of the PSAMP INFO
>>>>model, to implement the idea sketched above. We will send an example to
>>>>this list in a few days.
>>>>
>>>>Regards,
>>>>
>>>>    Juergen
>>>>
>>>>
>>>>--On 27.01.2004 23:55 h -0800 Jeff Meyer wrote:
>>>>
>>>>>The current info-model-02 specification contains references to XML type
>>>>>names and semantics borrowed directly from the XML-Schema specification 
>>>>>as
>>>>>well as extensions.
>>>>>
>>>>>Currently these extensions borrow from existing work of IPDR as well as
>>>>>newly identified types currently specific to IPFIX.
>>>>>
>>>>>There are a few ways to address this.
>>>>>
>>>>>The following e-mail thread discusses the options and opinion of this
>>>>>editor as well as opinions from Andrew Norton who is involved in IETF's
>>>>>and IANA's work in utilizing XML in RFC's.
>>>>>
>>>>>
>>>>>Jeff,
>>>>>
>>>>>It would seem that this is all a matter of "taste" as any of these 
>>>>>options
>>>>>technically work.  Personally I would go with option 3; though it 
>>>>>requires
>>>>>more coordination between organizations, to an outsider it would seem 
>>>>>more
>>>>>cohesive.
>>>>>
>>>>>There is a practical difference between option 1 and option 3 in terms 
>>>>>of
>>>>>setting the standard.  With option 3, if IPDR upgrades their standard, 
>>>>>the
>>>>>IPFIX group needs to do nothing to incorporate the changes.  However, 
>>>>>with
>>>>>option 1, IPFIX will have to
>>>>>standardize a new schema and issue new RFC's.
>>>>>
>>>>>-andy
>>>>>
>>>>>Jeff Meyer wrote:
>>>>>     Hi Andy,
>>>>>
>>>>>I wanted to get your opinion on extending the XML-Schema type system 
>>>>>for
>>>>>some specific information modeling requirements encountered by the 
>>>>>IPFIX
>>>>>working group.
>>>>>
>>>>>IPFIX currently reuses about 15 types from XML-Schema directly, however
>>>>>there are several types which are worthwile to distinguish from an 
>>>>>IPFIX
>>>>>persepective which are not defined by XML-Schema.
>>>>>
>>>>>These include types to identify timestamps of specific resolution (e.g.
>>>>>mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and one 
>>>>>for
>>>>>UUIDs.
>>>>>
>>>>>Today most of these extension types are defined in the public NDM-U 
>>>>>3.1.1
>>>>>specification from the industry consortium called IPDR.org.  There are 
>>>>>a
>>>>>couple which are not are related to the high resolution timestamps 
>>>>>(uSec
>>>>>and nSec).
>>>>>
>>>>>The NDM-U 3.1.1 specificaiton is avaiable at
>>>>>http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically section
>>>>>A.4.4.
>>>>>
>>>>>The IPFIX-Info reference is available at:
>>>>>
>>>>>http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#anchor4
>>>>>
>>>>>
>>>>>This is a link to the specific secion in the HTML format of the info 
>>>>>model
>>>>>based on RFC2629.
>>>>>
>>>>>
>>>>>The quesion at hand is whether to follow one of the following 3 
>>>>>options:
>>>>>
>>>>>    1. have a single XML-Schema which defines the extension types 
>>>>>relevant
>>>>>to IPFIX and contained in the IPFIX namespace
>>>>>    2. reference the existing types targeted by IPDR and add only the 
>>>>>new
>>>>>types specific to the IPFIX Schema
>>>>>    3. petition IPDR to define the remaining two IPFIX types for
>>>>>timestamps in their upcoming 3.5 specification (likely timeframe Feb. 
>>>>>or
>>>>>March)
>>>>>
>>>>>I get the impression from IPFIX discussions that referencing IPDR is
>>>>>something that some vocal participants find objectionable, i.e. they 
>>>>>would
>>>>>prefer to see option 1.
>>>>>
>>>>>My personal preference would be to go with option 3 or 2.  I believe 3 
>>>>>is
>>>>>doable and would reduce the number of places where people have to look 
>>>>>for
>>>>>things.  Option 1 I see as creating some confusion in the space, but
>>>>>ultimately addressable through XSL
>>>>>or other mapping functions, if that's what it takes to get consensus.
>>>>>
>>>>>
>>>>>Any guidance on your part would be appreciated.
>>>>>
>>>>>Regards,
>>>>>
>>>>>Jeff Meyer
>>>>>
>>>>>_________________________________________________________________
>>>>>Get a FREE online virus check for your PC here, from McAfee.
>>>>>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>>>>>
>>>>>
>>>>>--
>>>>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in 
>>>>>message
>>>>>body
>>>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>>>>"unsubscribe ipfix" in message body
>>>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>>
>>>>
>>>>
>>>>
>>>
>>>_________________________________________________________________
>>>Find high-speed ‘net deals ? comparison-shop your local providers here. 
>>>https://broadband.msn.com
>>>
>>
>>
>>
>>
>>
>>--
>>Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message 
>>body
>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
>>"unsubscribe ipfix" in message body
>>Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>
><< ipfix.xml >>
><< ipfix.xsd >>

_________________________________________________________________
High-speed users—be more efficient online with the new MSN Premium Internet 
Software. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 30 19:38:11 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29122
	for <ipfix-archive@lists.ietf.org>; Fri, 30 Jan 2004 19:38:11 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1Amim6-00002n-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jan 2004 18:14:14 -0600
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1Amim5-00002h-00
	for ipfix@net.doit.wisc.edu; Fri, 30 Jan 2004 18:14:13 -0600
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i0V0EANA026483
	for <ipfix@net.doit.wisc.edu>; Sat, 31 Jan 2004 01:14:11 +0100 (CET)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i0V0E6S4026482
	for <ipfix@net.doit.wisc.edu>; Sat, 31 Jan 2004 01:14:06 +0100 (CET)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i0V0E5N8026480; Sat, 31 Jan 2004 01:14:06 +0100 (CET)
Received: from [10.1.1.26] (dial02.office [10.1.1.26])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id EE0BF21F7B; Sat, 31 Jan 2004 01:14:02 +0100 (CET)
Date: Sat, 31 Jan 2004 01:14:16 +0100
From: Juergen Quittek <quittek@ccrle.nec.de>
To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations
Message-ID: <2147483647.1075511656@[10.1.1.26]>
In-Reply-To: <BAY3-F7dvdl1eCsgTG9000025df@hotmail.com>
References:  <BAY3-F7dvdl1eCsgTG9000025df@hotmail.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
Content-Transfer-Encoding: 7bit

Jeff,

Please find some comments inline.

--On 30.01.2004 13:36 Uhr -0800 Jeff Meyer wrote:

> Juergen,
>
>   Some interesting work.  I like some of the elements.
>
>   Comments inline.
>
> -- Jeff
>
>
>> From: Juergen Quittek <quittek@ccrle.nec.de>
>> To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>> Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA
>> considerations
>> Date: Fri, 30 Jan 2004 17:32:52 +0100
>>
>> Jeff and all,
>>
>> Here is an alternative suggestion for the XML representation of the
>> info model that I developed together with Thomas, one of the editors of
>> the PSAMP info model.  This XML representation of the info model uses
>> an XML document (ipfix.xml) instead of an XML schema for specifying
>> the IPFIX information elements (or fields as the IPFIX protocol document
>> calls them).
>
> Do you have XSL templates to go to/from this format to the more
> generally useful XML-Schema syntax?

Thomas and I are working on it.

>> It just shows the first 11 elements defined in the current draft,
>> but this is enough to show how this XML format looks like.
>>
>> File ipfix.xml can be used for automatically generating Section 6 of
>> the INFO model document as well as the XML schema used for the previous
>> version.
>
> Do you have that XSL template available publicly?

We will make it public, when it is complete.

>> The difference is that it uses abstract data types (as a data
>> model should) instead of concrete ones.
>
> How are these any more abstract?  Your ipfix.xsd in turn derives these
> shiny new names from existing XML Schema Types.  In other words new names,
> same thing.

The difference is that the encoding - and even the ASCII encoding - is open.

>>
>> In addition, file ipfix.xsd contains an XML schema, that can be used
>> for validating the ipfix.xml file. It defines the properties of fields/
>> information elements that are used in ipfix.xml and it also includes
>> a definition of the abstract data types used in ipfix.xml.
>
> So, one thing this does is provide validation that required annotations
> are present.  That could be useful.
>
> What you have lost is the ability to validate or have an XML format of
> the information simply fall out of the work.  This could be mitigated
> if you have the XML-Schema -> ipfix.xml XSL, do you have this?

Sorry, what are you asking for?

>> A nice consequence is that now not just Section 6 (field definitions)
>> but also Section 3 (Properties of an IPFIX Flow Attribute) and Section 4
>> (Type Space) can be generated out of XML input.
>
> This is interesting and potentially useful, with the exception of
> creating new names for lots of existing types.
>
> One benefit I see is that it would constrain and allow validation that
> only allowed types are present in this style information model.  Reusing
> well defined names from XML-Schema Types would obviously be my preference.
>
>>
>> While section 6 is generated from ipfix.xml, Sections 3 and 4 are
>> generated from ipfix.xsd.
>
> Do you have the XSL for this?

Not yet, but without them, this work would not make sense.

>> Also the XML schema, we used for the previous versions of the INFO model
>> can be generated out of the info model given in ipfix.xml.  You just have
>> to define a mapping of the used abstract data types to concrete ones,
>> such as the IPDR definitions of IPv4 and IPv6 addresses.
>
> OK, nice.
>
>>
>> Conclusion:
>> - This version is a pure data model using abstract data types and without
>>  any data encodings.
>
> Umm, you mean "pure information model"?

An information model that comes without a data model.

> I would say "This version is enables the validation of IPFIX information
> models using off the shelf tools" and enforces restrictions which are not
> assigned in the technique of using XML-Schema directly as an information
> model."
>
>> - It does not have dependencies on external data type definitions by IPDR.
>
> Thank god for that!
>
>> - We do not loose anything, because the XML schema, we used so far
>>  (including XML data types) can be generated automatically.
>
> If you have any of the XSL's I'd appreciate your making them public.

As I said, without them the entire effort does not make sense.
We will have them completed soon.

>  Ultimately having a direct representation in XML-Schema is useful
> for validating instance documents which contain sets of data serialized
> in this format, for use of IPDR's XML and
> XDR serialization tools and other things.
>
> So, in general, I agree there are some benefits which you've identified.
> As long as it doesn't take away other existing benefits, i.e. immediate
> mechanisms for serialization in XML and binary formats with open source
> tools.  Having bi directional XSL
> info-model.xml <-> info-model.xsd would be good.

Agreed.

Thanks,

    Juergen


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 30 21:24:39 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19757
	for <ipfix-archive@lists.ietf.org>; Fri, 30 Jan 2004 21:24:38 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmkcE-0003pc-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jan 2004 20:12:10 -0600
Received: from bay3-f15.bay3.hotmail.com ([65.54.169.15] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmkcD-0003pX-00
	for ipfix@net.doit.wisc.edu; Fri, 30 Jan 2004 20:12:09 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 30 Jan 2004 18:12:08 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Sat, 31 Jan 2004 02:12:08 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: quittek@ccrle.nec.de, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations
Date: Fri, 30 Jan 2004 18:12:08 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F15vqzAoa2JB1n00002fa0@hotmail.com>
X-OriginalArrivalTime: 31 Jan 2004 02:12:08.0915 (UTC) FILETIME=[A156EA30:01C3E79F]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Juergen,

  I'll look forward to the XSL tools, basically the "information modeling 
specific" XML document to/from XML-Schema.

  The ability to completely disconnect the type space from XML encoding 
introduces an ambiguity whose value I question.  But it is effectively 
irrelevant/equivalent if one uses a default XSL mapping from your 
specification format to the obvious XML type analogues used in XML-Schema.

  So, overall I see some benefits to this format, not the least of which 
being that some folks might be more willing to move forward, as it 
disconnects the work from that of other rogue non-IETF groups, but still 
leaves a straightforward mapping thanks to the power of XML transformations.

  It also provides a separation of concern which I can appreciate.

  Good work!

-- Jeff


>From: Juergen Quittek <quittek@ccrle.nec.de>
>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA 
>considerations
>Date: Sat, 31 Jan 2004 01:14:16 +0100
>
>Jeff,
>
>Please find some comments inline.
>
>--On 30.01.2004 13:36 Uhr -0800 Jeff Meyer wrote:
>
>>Juergen,
>>
>>   Some interesting work.  I like some of the elements.
>>
>>   Comments inline.
>>
>>-- Jeff
>>
>>
>>>From: Juergen Quittek <quittek@ccrle.nec.de>
>>>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>>>Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA
>>>considerations
>>>Date: Fri, 30 Jan 2004 17:32:52 +0100
>>>
>>>Jeff and all,
>>>
>>>Here is an alternative suggestion for the XML representation of the
>>>info model that I developed together with Thomas, one of the editors of
>>>the PSAMP info model.  This XML representation of the info model uses
>>>an XML document (ipfix.xml) instead of an XML schema for specifying
>>>the IPFIX information elements (or fields as the IPFIX protocol document
>>>calls them).
>>
>>Do you have XSL templates to go to/from this format to the more
>>generally useful XML-Schema syntax?
>
>Thomas and I are working on it.
>
>>>It just shows the first 11 elements defined in the current draft,
>>>but this is enough to show how this XML format looks like.
>>>
>>>File ipfix.xml can be used for automatically generating Section 6 of
>>>the INFO model document as well as the XML schema used for the previous
>>>version.
>>
>>Do you have that XSL template available publicly?
>
>We will make it public, when it is complete.
>
>>>The difference is that it uses abstract data types (as a data
>>>model should) instead of concrete ones.
>>
>>How are these any more abstract?  Your ipfix.xsd in turn derives these
>>shiny new names from existing XML Schema Types.  In other words new names,
>>same thing.
>
>The difference is that the encoding - and even the ASCII encoding - is 
>open.
>
>>>
>>>In addition, file ipfix.xsd contains an XML schema, that can be used
>>>for validating the ipfix.xml file. It defines the properties of fields/
>>>information elements that are used in ipfix.xml and it also includes
>>>a definition of the abstract data types used in ipfix.xml.
>>
>>So, one thing this does is provide validation that required annotations
>>are present.  That could be useful.
>>
>>What you have lost is the ability to validate or have an XML format of
>>the information simply fall out of the work.  This could be mitigated
>>if you have the XML-Schema -> ipfix.xml XSL, do you have this?
>
>Sorry, what are you asking for?
>
>>>A nice consequence is that now not just Section 6 (field definitions)
>>>but also Section 3 (Properties of an IPFIX Flow Attribute) and Section 4
>>>(Type Space) can be generated out of XML input.
>>
>>This is interesting and potentially useful, with the exception of
>>creating new names for lots of existing types.
>>
>>One benefit I see is that it would constrain and allow validation that
>>only allowed types are present in this style information model.  Reusing
>>well defined names from XML-Schema Types would obviously be my preference.
>>
>>>
>>>While section 6 is generated from ipfix.xml, Sections 3 and 4 are
>>>generated from ipfix.xsd.
>>
>>Do you have the XSL for this?
>
>Not yet, but without them, this work would not make sense.
>
>>>Also the XML schema, we used for the previous versions of the INFO model
>>>can be generated out of the info model given in ipfix.xml.  You just have
>>>to define a mapping of the used abstract data types to concrete ones,
>>>such as the IPDR definitions of IPv4 and IPv6 addresses.
>>
>>OK, nice.
>>
>>>
>>>Conclusion:
>>>- This version is a pure data model using abstract data types and without
>>>  any data encodings.
>>
>>Umm, you mean "pure information model"?
>
>An information model that comes without a data model.
>
>>I would say "This version is enables the validation of IPFIX information
>>models using off the shelf tools" and enforces restrictions which are not
>>assigned in the technique of using XML-Schema directly as an information
>>model."
>>
>>>- It does not have dependencies on external data type definitions by 
>>>IPDR.
>>
>>Thank god for that!
>>
>>>- We do not loose anything, because the XML schema, we used so far
>>>  (including XML data types) can be generated automatically.
>>
>>If you have any of the XSL's I'd appreciate your making them public.
>
>As I said, without them the entire effort does not make sense.
>We will have them completed soon.
>
>>  Ultimately having a direct representation in XML-Schema is useful
>>for validating instance documents which contain sets of data serialized
>>in this format, for use of IPDR's XML and
>>XDR serialization tools and other things.
>>
>>So, in general, I agree there are some benefits which you've identified.
>>As long as it doesn't take away other existing benefits, i.e. immediate
>>mechanisms for serialization in XML and binary formats with open source
>>tools.  Having bi directional XSL
>>info-model.xml <-> info-model.xsd would be good.
>
>Agreed.
>
>Thanks,
>
>    Juergen
>

_________________________________________________________________
There are now three new levels of MSN Hotmail Extra Storage!  Learn more. 
http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


From majordomo@mil.doit.wisc.edu  Fri Jan 30 21:30:05 2004
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19877
	for <ipfix-archive@lists.ietf.org>; Fri, 30 Jan 2004 21:30:05 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1AmkgL-0003se-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jan 2004 20:16:25 -0600
Received: from bay3-f37.bay3.hotmail.com ([65.54.169.37] helo=hotmail.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1AmkgK-0003sW-00
	for ipfix@net.doit.wisc.edu; Fri, 30 Jan 2004 20:16:24 -0600
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 30 Jan 2004 18:16:21 -0800
Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP;
	Sat, 31 Jan 2004 02:16:21 GMT
X-Originating-IP: [67.169.184.134]
X-Originating-Email: [inetpix@msn.com]
X-Sender: inetpix@msn.com
From: "Jeff Meyer" <inetpix@msn.com>
To: quittek@ccrle.nec.de, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations
Date: Fri, 30 Jan 2004 18:16:21 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY3-F37gKXG1bFGbSo0000304b@hotmail.com>
X-OriginalArrivalTime: 31 Jan 2004 02:16:21.0322 (UTC) FILETIME=[37C92AA0:01C3E7A0]
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>

Juergen,

  I'll look forward to the XSL tools, basically the "information modeling 
specific" XML document to/from XML-Schema.

  The ability to completely disconnect the type space from the existing XML 
encoding introduces an ambiguity whose value I question.  But it is 
effectively irrelevant/equivalent if one uses a default XSL mapping from 
your specification format to the obvious XML type analogues used in 
XML-Schema.

  So, overall I see some benefits to this format, not the least of which 
being that some folks might be more willing to move forward, as it 
disconnects the work from that of other rogue non-IETF groups, but still 
leaves a straightforward mapping thanks to the power of XML transformations.

  It also provides a separation of concern which I can appreciate.

  Good work!

-- Jeff





>From: Juergen Quittek <quittek@ccrle.nec.de>
>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA 
>considerations
>Date: Sat, 31 Jan 2004 01:14:16 +0100
>
>Jeff,
>
>Please find some comments inline.
>
>--On 30.01.2004 13:36 Uhr -0800 Jeff Meyer wrote:
>
>>Juergen,
>>
>>   Some interesting work.  I like some of the elements.
>>
>>   Comments inline.
>>
>>-- Jeff
>>
>>
>>>From: Juergen Quittek <quittek@ccrle.nec.de>
>>>To: Jeff Meyer <inetpix@msn.com>, ipfix@net.doit.wisc.edu
>>>Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA
>>>considerations
>>>Date: Fri, 30 Jan 2004 17:32:52 +0100
>>>
>>>Jeff and all,
>>>
>>>Here is an alternative suggestion for the XML representation of the
>>>info model that I developed together with Thomas, one of the editors of
>>>the PSAMP info model.  This XML representation of the info model uses
>>>an XML document (ipfix.xml) instead of an XML schema for specifying
>>>the IPFIX information elements (or fields as the IPFIX protocol document
>>>calls them).
>>
>>Do you have XSL templates to go to/from this format to the more
>>generally useful XML-Schema syntax?
>
>Thomas and I are working on it.
>
>>>It just shows the first 11 elements defined in the current draft,
>>>but this is enough to show how this XML format looks like.
>>>
>>>File ipfix.xml can be used for automatically generating Section 6 of
>>>the INFO model document as well as the XML schema used for the previous
>>>version.
>>
>>Do you have that XSL template available publicly?
>
>We will make it public, when it is complete.
>
>>>The difference is that it uses abstract data types (as a data
>>>model should) instead of concrete ones.
>>
>>How are these any more abstract?  Your ipfix.xsd in turn derives these
>>shiny new names from existing XML Schema Types.  In other words new names,
>>same thing.
>
>The difference is that the encoding - and even the ASCII encoding - is 
>open.
>
>>>
>>>In addition, file ipfix.xsd contains an XML schema, that can be used
>>>for validating the ipfix.xml file. It defines the properties of fields/
>>>information elements that are used in ipfix.xml and it also includes
>>>a definition of the abstract data types used in ipfix.xml.
>>
>>So, one thing this does is provide validation that required annotations
>>are present.  That could be useful.
>>
>>What you have lost is the ability to validate or have an XML format of
>>the information simply fall out of the work.  This could be mitigated
>>if you have the XML-Schema -> ipfix.xml XSL, do you have this?
>
>Sorry, what are you asking for?
>
>>>A nice consequence is that now not just Section 6 (field definitions)
>>>but also Section 3 (Properties of an IPFIX Flow Attribute) and Section 4
>>>(Type Space) can be generated out of XML input.
>>
>>This is interesting and potentially useful, with the exception of
>>creating new names for lots of existing types.
>>
>>One benefit I see is that it would constrain and allow validation that
>>only allowed types are present in this style information model.  Reusing
>>well defined names from XML-Schema Types would obviously be my preference.
>>
>>>
>>>While section 6 is generated from ipfix.xml, Sections 3 and 4 are
>>>generated from ipfix.xsd.
>>
>>Do you have the XSL for this?
>
>Not yet, but without them, this work would not make sense.
>
>>>Also the XML schema, we used for the previous versions of the INFO model
>>>can be generated out of the info model given in ipfix.xml.  You just have
>>>to define a mapping of the used abstract data types to concrete ones,
>>>such as the IPDR definitions of IPv4 and IPv6 addresses.
>>
>>OK, nice.
>>
>>>
>>>Conclusion:
>>>- This version is a pure data model using abstract data types and without
>>>  any data encodings.
>>
>>Umm, you mean "pure information model"?
>
>An information model that comes without a data model.
>
>>I would say "This version is enables the validation of IPFIX information
>>models using off the shelf tools" and enforces restrictions which are not
>>assigned in the technique of using XML-Schema directly as an information
>>model."
>>
>>>- It does not have dependencies on external data type definitions by 
>>>IPDR.
>>
>>Thank god for that!
>>
>>>- We do not loose anything, because the XML schema, we used so far
>>>  (including XML data types) can be generated automatically.
>>
>>If you have any of the XSL's I'd appreciate your making them public.
>
>As I said, without them the entire effort does not make sense.
>We will have them completed soon.
>
>>  Ultimately having a direct representation in XML-Schema is useful
>>for validating instance documents which contain sets of data serialized
>>in this format, for use of IPDR's XML and
>>XDR serialization tools and other things.
>>
>>So, in general, I agree there are some benefits which you've identified.
>>As long as it doesn't take away other existing benefits, i.e. immediate
>>mechanisms for serialization in XML and binary formats with open source
>>tools.  Having bi directional XSL
>>info-model.xml <-> info-model.xsd would be good.
>
>Agreed.
>
>Thanks,
>
>    Juergen
>

_________________________________________________________________
Learn how to choose, serve, and enjoy wine at Wine @ MSN. 
http://wine.msn.com/


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/