Re: [ipfix-protocol] PROTO-5, 6, 7, 8, 9, 10, 11: SCTP and SCTP-PR

>
>> 5.3.4 Collecting Process 
>> The Collecting Process SHOULD listen for a new association request 
>> from the Exporting Process. The Exporting Process will request a 
>> number of streams to use for export. A Collecting Process
>> MUST support a least two inbound streams per association. A Exporting 
>> Process and Collecting Process MAY ask for and support more than two 
>> streams.
>>
>> The Collecting Process SHOULD verify that the received IPFIX Messages 
>> inside one stream does not have differing SID values and silently 
>> discard any data that does NOT meet the collected values. The 
>> Exporting Process SHOULD NOT transmit messages inside one stream with 
>> multiple SID values. The correlated Flow Records are then treated 
>> like a normal export Flow.
>>
>> If the Collecting Process receives an IPFIX Message that it cannot 
>> decode, it SHOULD reset the SCTP association.
>>  
>>
> The last para should be changed to:
>
> If the Collecting Process receives an IPFIX Message that it cannot
> decode, it MUST reset the SCTP association, discard the message
> and log the error.
>
> and then we should add the following paragraph:
>
> When an SCTP association is closed, the Collecting Process MUST 

Re: [ipfix-protocol] PROTO-5, 6, 7, 8, 9, 10, 11: SCTP and SCTP-PR

Robert,

You've got some good points below regarding the section 13 "Template 
Management"
This section was initially written for UDP as a transport (long time 
ago...). As a consequence, it's not up to date.
The issue PROTO-25 addresses this.

       PROTO-25: The section 11 "Template Management" will have to updated
       according to the transport protocol.
       - For example, the point 2 of the section "Template Management".
         Remark: the template management will vary with TCP, SCTP,
         etc...
         Must have both sections updated: transport updated and
         template  management sections (BTW, this is the same for
         the failover section).

We should first agree on the 3 transport sections, and then change this 
section 13.

Regards, Benoit.

> Stewart Bryant wrote:
>
>>
>>> 5.3.4 Collecting Process The Collecting Process SHOULD listen for a 
>>> new association request from the Exporting Process. The Exporting 
>>> Process will request a number of streams to use for export. A 
>>> Collecting Process
>>> MUST support a least two inbound streams per association. A 

[ipfix-protocol] IPFIX over UDP transport

I would like to propose the following text be added to
draft-ietf-ipfix-protocol-4.txt to describe operation over
UDP

- Stewart

5.3 UDP

This section describes how IPFIX can be transported over UDP
[RFC768]

5.3.1 Congestion Avoidance

UDP has no integral congestion avoidance mechanism. Its use
over congestion sensitive network paths is therefore deprecated.
UDP MAY  be used in deployments where exporters and collectors
always communicate over dedicated links which are not susceptible
to congestion.

5.3.2 Reliability

UDP is not a reliable transport protocol, and cannot guarantee
delivery of messages. IPFIX Messages sent from the Exporting
Process to the Collecting Process using UDP may therefore be lost.
UDP MUST NOT be used unless the application can tolerate some
loss of Messages.

The IPFIX Message sequence number in the packet header indicates
the lost of IPFIX Messages to the Collecting Process.

Re: [ipfix-protocol]PROTO-4: IPFIX over UDP transport

Hi,

On the top of this, I will be creating a new issue, as I'm not sure we 
will have to time to create to solve this issue before the deadline.

  Issues in the Template Management section
  PROTO-29: The insertion of the new transport protocol sections   has 
highlighted some inconsistency in the section 13  (template management) 
and the section 14 (The Collecting Process's Side).

Regards, Benoit.

> I would like to propose the following text be added to
> draft-ietf-ipfix-protocol-4.txt to describe operation over
> UDP
>
> - Stewart
>
>
> 5.3 UDP
>
> This section describes how IPFIX can be transported over UDP
> [RFC768]
>
> 5.3.1 Congestion Avoidance
>
> UDP has no integral congestion avoidance mechanism. Its use
> over congestion sensitive network paths is therefore deprecated.
> UDP MAY  be used in deployments where exporters and collectors
> always communicate over dedicated links which are not susceptible

Re: [ipfix-protocol] PROTO-5, 6, 7, 8, 9, 10, 11: SCTP and SCTP-PR

Benoit Claise wrote:

Benoit/Stewart,

> You've got some good points below regarding the section 13 "Template 
> Management"
> This section was initially written for UDP as a transport (long time 
> ago...). As a consequence, it's not up to date.
> The issue PROTO-25 addresses this.
> 
>       PROTO-25: The section 11 "Template Management" will have to updated
>       according to the transport protocol.
>       - For example, the point 2 of the section "Template Management".
>         Remark: the template management will vary with TCP, SCTP,
>         etc...
>         Must have both sections updated: transport updated and
>         template  management sections (BTW, this is the same for
>         the failover section).
> 
> We should first agree on the 3 transport sections, and then change this 
> section 13.

Understood.  Any comments on section 14?  I'm mostly confused about how
the collector process is to uniquely identify template IDs as belonging
to a unique observation domain (Stewart's revised text wanted the collector
process to discard them under a couple of error conditions).  Unless I
am mistaken, observation domain/SID and template ID are assigned by the
exporter.  How are collisions avoided?  IPV4/V6 socket from the exporter?
If so, that should be included in the list of 'SHOULD maintain', right?

Re: [ipfix-protocol]PROTO-4: IPFIX over UDP transport

Benoit Claise wrote:
>> 5.3.7 Failover
>>
>> Because UDP is not a connection oriented protocol, the Exporting Process
>> is unable to determine from the transport protocol that the Collecting
>> Process is no longer able to receive the IFPIX Messages. Therefore, it
>> can not invoke a failover mechanism. However, the Exporting Process
>> MAY duplicate the IPFIX Message to the several Collecting Process.
>>

Probably it is better to change the wording slightly:

"... the Exporting Process _may be_ unable to determine". The Exporter
is actually able to detect some of the cases when the Collecting Process
is not able to receive the IPFIX Messages. For example, an ICMP message
may be sent to indicate that there is no listener on the chosen UDP port.

However, if the Exporting Process is actually able to react on this kind
of messages (ICMP Port Unreachable), then there is a possibility for
a remote attack.  A remote system may maliciously send an ICMP Port 
Unreachable to the Exporter to make it redirect UDP traffic to another node or
perform other potentially costly operations.

Bottom line: either a reaction on the ICMP messages should be explicitly
prohibited for UDP, or it may be allowed, but a security section needs to
be created to address the above issue.

--

-- 
Lev Walkin
vlm <at> netli.com

Re: [ipfix-protocol]PROTO-4: IPFIX over UDP transport

Lev Walkin wrote:

> Benoit Claise wrote:
>
>>> 5.3.7 Failover
>>>
>>> Because UDP is not a connection oriented protocol, the Exporting 
>>> Process
>>> is unable to determine from the transport protocol that the Collecting
>>> Process is no longer able to receive the IFPIX Messages. Therefore, it
>>> can not invoke a failover mechanism. However, the Exporting Process
>>> MAY duplicate the IPFIX Message to the several Collecting Process.
>>>
>
> Probably it is better to change the wording slightly:
>
> "... the Exporting Process _may be_ unable to determine". The Exporter
> is actually able to detect some of the cases when the Collecting Process
> is not able to receive the IPFIX Messages. For example, an ICMP message
> may be sent to indicate that there is no listener on the chosen UDP port.
>
> However, if the Exporting Process is actually able to react on this kind
> of messages (ICMP Port Unreachable), then there is a possibility for
> a remote attack.  A remote system may maliciously send an ICMP Port 
> Unreachable to the Exporter to make it redirect UDP traffic to another 
> node or
> perform other potentially costly operations.
>
> Bottom line: either a reaction on the ICMP messages should be explicitly

RE: [ipfix-protocol]PROTO-4: IPFIX over UDP transport

Layer 4 and above functions don't normally get involved
in how layer 3 (IP) responds to its control messages (ICMP).
IPFIX shouldn't try to go down that path.

Just an opinion.

Carter 

-----Original Message-----
From: majordomo listserver [mailto:majordomo <at> mil.doit.wisc.edu] On Behalf Of
Stewart Bryant
Sent: Friday, July 16, 2004 4:33 AM
To: Lev Walkin
Cc: Benoit Claise; ipfix-protocol <at> net.doit.wisc.edu
Subject: Re: [ipfix-protocol]PROTO-4: IPFIX over UDP transport

Lev Walkin wrote:

> Benoit Claise wrote:
>
>>> 5.3.7 Failover
>>>
>>> Because UDP is not a connection oriented protocol, the Exporting 
>>> Process
>>> is unable to determine from the transport protocol that the Collecting
>>> Process is no longer able to receive the IFPIX Messages. Therefore, it
>>> can not invoke a failover mechanism. However, the Exporting Process
>>> MAY duplicate the IPFIX Message to the several Collecting Process.
>>>

Re: [ipfix-protocol]PROTO-4: IPFIX over UDP transport

Carter Bullard wrote:
> Layer 4 and above functions don't normally get involved
> in how layer 3 (IP) responds to its control messages (ICMP).
> IPFIX shouldn't try to go down that path.

In Linux, the UDP socket will get blocked on receipt of ICMP PU,
and return errors on subsequent attempts to send data. The program
will have to deal with this situation anyway, so whyn't just mandate
that these errors must be ignored (using getsockopt() to clear the
error state on socket every time this situation occurs).

> Just an opinion.
> 
> Carter 
> 
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo <at> mil.doit.wisc.edu] On Behalf Of
> Stewart Bryant
> Sent: Friday, July 16, 2004 4:33 AM
> To: Lev Walkin
> Cc: Benoit Claise; ipfix-protocol <at> net.doit.wisc.edu
> Subject: Re: [ipfix-protocol]PROTO-4: IPFIX over UDP transport
> 
> 
> Lev Walkin wrote:
> 
> 
>>Benoit Claise wrote:
>>
>>

[ipfix-protocol] New version of the IPFIX protocol draft posted