Subject: [ipfix-protocol] Proposed TCP section

From: Stewart Bryant <[email-masked]>
Date: Tue, 19 Oct 2004 13:58:37 +0100

I have extracted the key elements of the mechanism
described in <draft-leinen-ipfix-tcp-00>
to carry IPFIX over TCP, and propose that this
text be incorporated in the IPFIX protocol draft.

Please can you comment ASAP so that Benoit and I can
incorporate into the next rev of the protocol
draft.

- Stewart

ISSUES

2.1  Handshake

Should we introduce a handshake sequence at the start of the
connection? A simple ASCII-based handshake could be used to
request TLS.

2.2  TLS

It would make sense to add TLS support even in the absence of a
handshake.  It would be the responsibility of the collector
(connection initiator) to know whether TLS setup is required.

---------------------------------------------------------------

5.2     TCP

This section describes how IPFIX can be transported over TCP
[TCP].

5.2.1 Congestion Avoidance

TCP will detect congestion in the end-to-end path between
the IPFIX Exporting Process and the IPFIX Collecting Process,
and limit the transfer rate accordingly.  When an IPFIX
Exporting Process has records to export, but detects that
transmission by TCP is temporarily impossible, it can either
wait until sending is possible again, or it can decide to drop
the record.  In the latter case, the dropped export data MUST
be accounted for, so that the amount of dropped export data can
be reported.

5.2.2 Reliability

TCP provides an intrinsically reliable delivery service from the
IPFIX Exporting Process to the IPFIX Collecting Process.

5.2.3 MTU

TCP provides the required IPFIX Message fragmentation
service based on path MTU discovery.

5.3.4 Exporting Process

The following sections describe how an IPFIX-over-TCP
connection is created, how IPFIX data is transferred
over it, and how a connection is to be terminated.

5.3.4.1 Connection Establishment

The IPFIX Exporting Process initiates a TCP connection to the
IPFIX Collecting Process.  By default, the Collecting Process
listens for connections on TCP port XXXX (to be assigned by
IANA).  It MUST be possible to configure both the Exporting
and Collecting Processes to use a different TCP port.

An Exporting Process MAY support more than one active
connection to different Collecting Processes (including
the case of different Collecting Processes on the same host).

5.3.4.2 Connection Release

When an Exporting Process has no more IPFIX Messages to send,
it SHOULD close the TCP connection.

When a Collecting Process no longer wants to receive IPFIX
messages, it SHOULD close the TCP connection, but SHOULD
continue to receive and process IPFIX messages until the
Exporting Process has closed its end.

When an Collecting Process detects that the TCP
connection to the Exporting Process is broken, it MUST
continue to listen for a new connection.

When an Exporting Process detects that the TCP
connection is abnormally terminated, it SHOULD try to
re-establish the connection.

Connection timeouts SHOULD be configurable.

5.3.4.3  IPFIX Message Encoding

TCP provides message boundary marking marking
mechanism. When IPFIX Message are sent over a
TCP connection, the LENGTH field in the IPFIX
Message header defines the end of each message
and the start of the next message.

If an Exporting Process exports data from multiple
Observation Domains, it should be careful to choose
the IPFIX Message lengths appropriately to avoid
head-of-line blocking between different Observation
Domains.

5.3.4.4  Templates

New Template Records SHOULD be transmitted as
soon as they are created on the Metering Process,
and preferably before any associated Flow and
Options Data Record is transmitted.  The Collecting
Process SHOULD accept Flow and Options Data Records
without the associated Template Record.

A Collecting Process MUST record all Template
and Option Template Records for the duration
of the connection, as an Exporting Process is
not required to re-export Template Records.

5.3.5 Fail-over

If the Collecting Process does not acknowledge the
attempt by the Exporting Process to establish a
connection, the Exporting Process should retry.
The retry schedule SHOULD be configurable.  In
the default configuration, an Exporting Process
MUST NOT attempt to establish a connection more
frequently than once per minute.

The Exporter MAY log an alarm if the time to
establish the association exceeds a specified
threshold.

If Collecting Process fail-over is supported by the
Exporting Process a second TCP connection MAY be
opened in advance.

------------------------------------------------
TCP specific security considerations

Because there is no handshake protocol once a TCP
connection is established, negotiation-based
transport-layer security protocols such as TLS
[RFC2246] cannot be used in a straightforward
manner to ensure authenticity and confidentiality.

Exporters and collectors MUST implement IPSEC [RFC2401]
with the Authentication Header (AH) [RFC2402] to
ensure authenticity of the exporter and the collector.
Exporters SHOULD implement IPSEC Encapsulating Security
Payload (ESP) [RFC2406] to ensure confidentiality of
the exported data.  The use of AH and ESP MUST be
configurable for each exporter/collector pair.

It MUST be possible to configure, an Exporting Process
to authenticate itself to the Collecting Process.
This authentication mechanism SHOULD be capable of
using strong identities such as IKE [RFC2409] public-key
certificates or pre-shared keys.  A Collecting Process
SHOULD detect and log unauthorized connection attempts.

-------------------------------------------------

IANA Considerations

IANA should assign a well-known TCP port number for IPFIX
over UDP, TCP and SCTP. It is recommended that the same
well-known port number is used as a default for all three
transport protocols.

EDITOR NOTE: once the SCTP, TCP and UDP ports are assigned,
The text in this draft might be updated.

-------------------------------------------------------
Normative references

[RFC2401]  Kent, S. and R. Atkinson, "Security
            Architecture for the Internet Protocol",
            RFC 2401, November 1998.

[RFC2409]  Harkins, D. and D. Carrel, "The Internet
Key Exchange (IKE)", RFC 2409, November 1998.

Informative References

[RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol
Version 1.0", RFC 2246, January 1999.

--
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: Simon Leinen <[email-masked]>
Date: Mon, 25 Oct 2004 13:52:35 +0200

> text be incorporated in the IPFIX protocol draft.

Um, I thought the agreement was that I'd do another revision of
draft-leinen-ipfix-tcp, and we'd integrate that into
draft-ietf-ipfix-protocol later on.  Anyway.

> connection? A simple ASCII-based handshake could be used to

I suggest to remove the "Handshake" issue.  I raised that at the last
meeting and there didn't seem to be any support for adding a
handshake.

Unless somebody disagrees on this list, I would assume that everything
that both sides (exporter and collector) need to know about their
association and about each other must somehow be configured in
advance, outside of the IPFIX protocol.

> (connection initiator) to know whether TLS setup is required.

This is something I'd really like to have in.  It would require a
(short) subsection on how TLS would be initiated, and what should
happen when both sides aren't consistently configured (one side
expects TLS to be used, the other doesn't).  I have added the
following to draft-leinen-ipfix-tcp-01.txt:

    3.5  TLS Usage
    
       Configuration of both the exporter and the collector may
       specify that Transport Layer Security (TLS) [RFC2246] must be
       used.
    
    3.5.1  Starting a session using TLS
    
       When an exporter opens a TCP connection to a collector for
       which use of TLS has been configured, the exporter MUST
       immediately start a TLS negotiation on this connection.  The
       exporter SHOULD immediately abort the connection when TLS
       negotiation fails for some reason.
    
       When a collector accepts a connection from an exporter for
       which use of TLS has been configured, the collector MUST wait
       for the exporter to start negotiating TLS.
    
    3.5.2  Authentication
    
       Exporter and collectors with TLS support SHOULD allow the
       configuration of both the permitted levels of encryption, and
       of the authorized identities to which data should be exported
       or, respectively, from which data should be received.
    
       After successful TLS negotiation, the collector and exporter
       should each decide whether the required level of authentication
       and/or privacy was achieved.  If this is not the case, the
       connection MUST be closed immediately; an exporter MUST NOT
       send any IPFIX data, and an collector MUST ignore any IPFIX
       data received.
    
    3.5.3  Closing a session using TLS
    
       When TLS is used, the exporter SHOULD always send a
       close_notify alert before closing the TCP connection.

This overlaps with section 14.2 of draft-ietf-ipfix-protocol-06.txt.
My text is partly derived from RFC 3207 (STARTTLS SMTP Extension).

> 5.2.1 Congestion Avoidance

I still don't like the structure of the transport mapping sections!

In my opinion, they should first describe how the mapping operates,
and maybe later analyze in how far "congestion avoidance" and
"reliability" are achieved by that mapping.

Starting with blanket assurances about congestion avoidance and
reliability doesn't help understanding the mappings.  To me this
sounds way too much like marketing blurb.

> be accounted for, so that the amount of dropped export data can

The previous text is taken almost verbatim from
draft-leinen-ipfix-tcp-00.  Why did you drop the next paragraph?

       "When an exporter finds that the rate at which flow records
	should be exported is consistently higher than the rate at
	which TCP permits to send, it SHOULD adapt the metering
	process so that it generates a lower amount of data, for
	example by increasing the sampling interval, or by increasing
	the amount of aggregation.  If it does this, the exporter
	SHOULD periodically attempt to switch back to the original
	metering configuration when congestion subsides."

> service based on path MTU discovery.

TCP and Path MTU Discovery are largely orthogonal - TCP provides the
same services whether PMTDU is used or not, only more or less
efficiently.

And what is this "required IPFIX Message fragmentation service"? I
cannot find it in RFC 3917.  Let's leave this section out.  We really
don't have to talk about IP MTUs here.

I still think it would be useful to talk about the permitted size of
IPFIX *messages* though.  In draft-leinen-ipfix-tcp, I have a section
that says

	  The 16-bit LENGTH field limits the length of a message to
	  65536 octets including the header.  A collector MUST be able
	  to handle message lengths of up to 65536 octets.

Because the length field in IPFIX messages is a 16-bit unsigned,
requiring every collector to handle 65536-octet messages sounds
reasonable to me.

> and Collecting Processes to use a different TCP port.

Should we actually request a IANA-assigned port? For my own
Netflow/IPFIX deployment I'd have to use multiple port numbers anyway,
so a well-known port doesn't help me much.

Arguments for a well-known port number:

* Makes exporter/collectors easier to configure
* Makes firewall rules easier to set up
* Makes debugging easier with tools like Ethereal
... but all this only in simple configurations

Arguments against a well-known port number:

* Asking IANA for one will delay RFC publication by XXX days
  (but a single well-known port should be easy)
* We don't want to deplete the limited resource of well-known port
  numbers for exotic protocols such as IPFIX

> mechanism.

I suggest "TCP provides no message boundary marking mechanism."

> When IPFIX Message are sent over a

  When IPFIX Messages ...

> and the start of the next message.

At this point in draft-leinen-ipfix-tcp-00.txt, there was the section
about message sizes I mentioned above.  Did you elide it because this
is a transport mapping-independent concern? Are you planning to add
some text on this to the protocol I-D?

> manner to ensure authenticity and confidentiality.

Actually, I now think that it would be quite possible to use TLS
(based on mutual pre-configuration), and that this would be a
completely valid, even superior, alternative to IPsec - see above.

> Exporters and collectors MUST implement IPSEC [RFC2401]
                                          ^
                                          IPsec
                                      (my mistake)

> Exporters SHOULD implement IPSEC Encapsulating Security
                             ^
                             IPsec

> It MUST be possible to configure, an Exporting Process
                                  ^
                  I believe this comma is incorrect.

>             Architecture for the Internet Protocol",

I would add RFC793 (TCP), RFC2402 (AH), RFC 2406 (ESP).

-- 
Simon.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 25 Oct 2004 15:11:09 +0100

Simon

See inline. It's too late for this pass, but the text should
incorporate your comments in the next pass.

> draft-ietf-ipfix-protocol later on.  Anyway.

There was a misunderstanding. The problem was that without
the TCP text we could not finish the protocol draft. Now we
did not quite finish it (but we did try).  Benoit would like
to square away the remaining issues before the meeting
so expect more text to the list.

> advance, outside of the IPFIX protocol.

Yes, until (if) we ever introduce an IPFIX config protocol there
is so much config that is needed we should do this by config as well.

> following to draft-leinen-ipfix-tcp-01.txt:

OK, that text should be added to the protocol draft.

> sounds way too much like marketing blurb.

There is some history there because - as you know - this issue
was a key factor in the early transport discussions. We should
perhaps change the ordering around, but we should do it
consistently across all transport types.

> 	metering configuration when congestion subsides."

Tho reasons: Ipfix protocol really deals with the record transport
and not with the metering process (that's PSAMP's teritory), and
this is a metering problem. Secondly this is more of an
implementation rather than an interworking issue anyway,
and as such it may not belong in any IETF spec.

I suppose you could replace the above with something of the form

"If transport experiences congestion it should notify the metering
process"

but specifying the action is I think wrong, because the right action
will depend on the application. The above statement should go in some
generic place anyway because it applies to all transports except UDP.

>>service based on path MTU discovery.

As I recall I pulled it over because it was also in SCTP. We should
probably take it out from both.

> requiring every collector to handle 65536-octet messages sounds

That is really an IPFIX issue rather that a transport issue. We
should probably delete it from the transport details (except
to say that UDP can't even do this), and MAYBE say somewhere
in the global trnsport text that messages must be no bigger than 
transport can support but we recommend that should where
possible support messages sizes of up 65536 (less any gatepost problems)

>   numbers for exotic protocols such as IPFIX

Again common to SCTP which has been around for a while. Whatever
we do we should do the same in both cases.

I am not sure that the XXX days is the issue, and nor am I sure that
IPFIX is more exotic than many of the protocols that already have
ports.

It's really a WG call, so we need to text consensus.

> I suggest "TCP provides no message boundary marking mechanism."

Yes, typo

>>When IPFIX Message are sent over a

OK

> some text on this to the protocol I-D?

See above

> completely valid, even superior, alternative to IPsec - see above.

OK, we will include your text.

>                   I believe this comma is incorrect.

OK

> I would add RFC793 (TCP), RFC2402 (AH), RFC 2406 (ESP).

OK