Subject: draft-ietf-ipfix-protocol-26.txt

From: [email-masked] (Scott O. Bradner)
Date: Tue, 25 Sep 2007 07:16:08 -0400 (EDT)

I reviewed draft-ietf-ipfix-protocol-26.txt as part of the Transport
Area review effort.

I did not find any particular issues in the described technology - a few
nits:

section 3.1 "Export Time" someday the IETF needs to stop using 32-bit
"seconds since 1 jan 1970" for timing - at least within in the next 31
years

section 6.1.2 - it might be reasonable to add the IEEE 8-byte MAC
address as an address type - this is used in ZigBee and may be in wider
use in the future

section 10.3.3 - a max packet size of 1280 could be used if the
connection is known to be running in an IPv6-only environment

I'm not sure why the packet size discussion is only listed for UDP - it
seems like the same restriction should apply to all protocols -
fragmentation is not your friend

Historically the biggest issue with IPFIX has been that most
implementers want to run it over UDP with consequences be dammed.  -
this was weaseled in the IPFIX Requirements document (RFC 3917) by
requiring (in section 6.3.1) that "For the data transfer, a congestion
aware protocol must be supported."  This draft meets that requirement by
making the implementation of SCTP a MUST.  That will not stop many
implementers from ignoring the requirement for implementation or users
to enable UDP and thus creating a potentially very high bandwidth
non-congestion avoiding fire hose that can quite easily wipe out a net
by misconfiguration or become a DoS engine by purposeful configuration.

I'm not sure if anything can be actually be done about this risk - It
might help some to say that UDP is a "MUST NOT" but I doubt it - in any
case it would help somewhat, imho, to expand section 10.3 to be clearer
about the threats posed by any use of a non-congestion avoiding
transport protocol or to do that in the Security Considerations section

Scott

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 25 Sep 2007 17:48:40 +0200

Scott,

Please note the note included in the IETF Last Call: 

> A previous version draft-ietf-ipfix-protocol-24.txt of this draft was
already approved by the IESG. The IPFIX WG decided to make changes to
that version of the document with the principal goal of removing the
SCTP stream 0 restriction. Reviews should focus on the changes since
draft-ietf-ipfix-protocol-24.txt which are mentioned in an editorial
note currently placed after the Table of Contents.

I believe that none of your comments refers to the changes since
draft-24. Do you consider any of your notes critical to the point that
we should reopen aspects of the protocol already approved by the IESG? 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Scott O. Bradner [mailto:[email-masked]] 
> Sent: Tuesday, September 25, 2007 1:16 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: draft-ietf-ipfix-protocol-26.txt
> 
> I reviewed draft-ietf-ipfix-protocol-26.txt as part of the 
> Transport Area review effort.
> 
> section 3.1 "Export Time" someday the IETF needs to stop 
> using 32-bit "seconds since 1 jan 1970" for timing - at least 
> within in the next 31 years
> 
> section 6.1.2 - it might be reasonable to add the IEEE 8-byte 
> MAC address as an address type - this is used in ZigBee and 
> may be in wider use in the future
> 
> section 10.3.3 - a max packet size of 1280 could be used if 
> the connection is known to be running in an IPv6-only environment
> 
> I'm not sure why the packet size discussion is only listed 
> for UDP - it seems like the same restriction should apply to 
> all protocols - fragmentation is not your friend
> 
> implementers want to run it over UDP with consequences be 
> dammed.  - this was weaseled in the IPFIX Requirements 
> document (RFC 3917) by requiring (in section 6.3.1) that "For 
> the data transfer, a congestion aware protocol must be 
> supported."  This draft meets that requirement by making the 
> implementation of SCTP a MUST.  That will not stop many 
> implementers from ignoring the requirement for implementation 
> or users to enable UDP and thus creating a potentially very 
> high bandwidth non-congestion avoiding fire hose that can 
> quite easily wipe out a net by misconfiguration or become a 
> DoS engine by purposeful configuration.
> 
> I'm not sure if anything can be actually be done about this 
> risk - It might help some to say that UDP is a "MUST NOT" but 
> I doubt it - in any case it would help somewhat, imho, to 
> expand section 10.3 to be clearer about the threats posed by 
> any use of a non-congestion avoiding transport protocol or to 
> do that in the Security Considerations section
> 
> Scott
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Sep 2007 23:02:52 +0100

Scott
> transport protocol or to do that in the Security Considerations section

There is text in section 10.1 which states:

UDP MAY be used although it is not a congestion aware protocol.  
However, the IPFIX traffic between Exporter and Collector MUST run 
in an environment where IPFIX traffic has been provisioned for or is 
contained through some other means. 

This sets out the set of conditions that MUST be fulfilled in order to 
run IPFIX over
UDP safely.

Stewart

---

From: [email-masked] (Scott O. Bradner)
Date: Tue, 25 Sep 2007 18:11:42 -0400 (EDT)

yeh - I read that but am not convinced that the message is clear 
enough of what can happen if those rules are not followed

Scott

---
Date: Tue, 25 Sep 2007 23:02:52 +0100
From: Stewart Bryant <[email-masked]>
To: "Scott O. Bradner" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt

Scott

Stewart