Subject: [ipfix-protocol] IPFIX over UDP transport

From: Stewart Bryant <[email-masked]>
Date: Thu, 15 Jul 2004 16:02:25 +0100

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.

Templates sent from the Exporting Process to the Collecting
Process using UDP as a transport MUST be resent at regular
intervals in case previous copies were lost. Implementations
MAY send templates using a reliable transport protocol, and
send IPFIX Flow and Option Data Records using UDP as the
transport protocol.

5.3.3 MTU

The maximum size of exported messages MUST be configured such that
the total packet size does not exceed the path MTU.

5.3.4 Port Numbers

The UDP destination port is set by manual configuration at both
Exporting Process and Collecting Process.

The UDP source port is allocated from the dynamic and/or
private ports space.

5.3.5    Exporting Process

The Exporting Process MAY duplicate the IPFIX Message
to the several Collecting Process.

5.3.5.1  Template

If sent using UDP as the transport protocol, Templates FlowSets
and Option Template FlowSets MUST be re-sent at regular intervals.
New Template Records SHOULD be transmitted as soon as they are
created on the Metering Process, and before any associated Data
Record is transmitted. The Collecting Process SHOULD accept
Data Records without the associated Template Record.

5.3.6 Collecting Process

If the Collecting Process receives an IPFIX Message that it cannot
decode, it MUST discard the message and log the error.

The Collecting Process must associate a lifetime with each
Template received via UDP. If the template is not refreshed by the
Exporting Process before that lifetime has expired, the
Collecting process MUST discard the Template. The Collecting
Process MUST NOT decode Flow or Option Data Records which
have an expired Template.

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.

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Benoit Claise <[email-masked]>
Date: Thu, 15 Jul 2004 17:36:08 +0200

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.

---

From: Lev Walkin <[email-masked]>
Date: Fri, 16 Jul 2004 00:44:10 -0700

>> 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
[email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 16 Jul 2004 09:32:48 +0100

> be created to address the above issue.

Securing against malicious ICMP is likely to be messy, so I would suggest
prohibiting taking notice of it.

- Stewart

---

From: "Carter Bullard" <[email-masked]>
Date: Fri, 16 Jul 2004 09:39:03 -0400

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:[email-masked]] On Behalf Of
Stewart Bryant
Sent: Friday, July 16, 2004 4:33 AM
To: Lev Walkin
Cc: Benoit Claise; [email-masked]
Subject: Re: [ipfix-protocol]PROTO-4: IPFIX over UDP transport

- Stewart

--
Help        mailto:[email-masked] and say "help" in message
body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Lev Walkin <[email-masked]>
Date: Sat, 17 Jul 2004 03:14:48 -0700

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

-- 
Lev Walkin
[email-masked]