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:sob(_at_)harvard(_dot_)edu]
Sent: Tuesday, September 25, 2007 1:16 PM
To: ietf(_at_)ietf(_dot_)org
Cc: ipfix(_at_)ietf(_dot_)org; tsv-dir(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf