Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt
over a period of packets in order to increase the likelihood that the Collector has received the Template. Template Withdraw messages MUST NOT be sent over UDP; the Exporter must rely on expiration at the Collector to expire old Templates or to reuse Template Ids. We recommend that the collector implements a template expiry of three times the Exporter refresh rate. However, since the IPFIX protocol doesn't provide any mechanism for the Exporter to convey any information about the Template expiry time to the Collector, configuration must be done out of band. If no out of band configuration is made, we recommend to initially set a template expiry time at the Collector of 60 minutes. The Collecting Process MAY estimate each Exporting Process's resend time and adapt the expiry time for the corresponding Templates accordingly. Scott O. Bradner wrote: 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 ___ IPFIX mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ipfix ** E-mail Confidentiality Notice and Disclaimer. This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. E-mail messages are not necessarily secure. Hitachi does not accept responsibility for any changes made to this message after it was sent. Hitachi checks outgoing e-mail messages for the presence of computer viruses. ** ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt
we received similar comments during the transport directorate review of the IPFIX implementation guidelines. The new revision of the document, now available at: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-implementation-guidelines-07.txt might address your concerns. I'm copying the UDP section here below for your convenience. this text is good as far as it goes, I'd suggest adding specific 'you may easily kill the network' language (along the lines of what I said in a previous message) - that warning is more implied than stated in the current text then it would be good to add a specific pointer to that section of the guidelines in the UDP section of the protocol document thanks Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-ietf-ipfix-protocol-26.txt
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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-ipfix-protocol-26.txt
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 PROTECTED] Sent: Tuesday, September 25, 2007 1:16 PM To: ietf@ietf.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: draft-ietf-ipfix-protocol-26.txt 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt
Scott 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 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt
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 PROTECTED] To: Scott O. Bradner [EMAIL PROTECTED] Cc: ietf@ietf.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt Scott 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 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
