Ran, > I am troubled by the apparent decision to ignore legitimate > operational security considerations (e.g. about covert channels)
We should certainly mention the covert channels issue in the security considerations of 3697bis. > and also the apparent decision to write these documents > in a manner intended to legislate reasonable security measures > (if applicable only in selected deployments) out of existence. I don't understand this comment. The flow label has always been defined as immutable; the consensus in the WG is to keep that property. So a firewall that overwrites it is unambiguously breaking the standard. Regards Brian On 2011-05-03 21:47, RJ Atkinson wrote: > Hi, > > My thanks to all of the editors for their joint work to sort out > these drafts and to progress them together. It is substantial > work to undertake. The drafts generally seem fine and are > eminently readable. > > However, the "Security Considerations" for both > draft-ietf-6man-flow-ecmp-02 and draft-ietf-6man-flow-3697bis > seem not to mention the issue where the IPv6 Flow Label field > is a relatively high-bandwidth covert channel. This means the > Security Considerations for those 2 I-Ds are incomplete. > > I'm pleased that the covert channel issue is discussed on page 4 > of draft-ietf-6man-flow-update-05. This covert channel issue is > one reason why a number of deployed IPv6-capable firewalls (and > other similar security appliances) clear the IPv6 Flow Label > (e.g. in financial/trading environments where M&A information > has very high monetary value). > > I request that this operational security concern, which is entirely > legitimate albeit not applicable to all operational environments, > at least be mentioned at the top of page 11 of draft-ietf-6man-flow-3697bis > (i.e. where the fact that Flow Labels will continue to be zeroed > in some deployments is noted). At present, the words there seem > to imply that the zeroing behaviour is illogical, silly, and/or wrong > -- when in fact it is logical, sensible, and quite correct in certain > deployments. I would be MUCH happier if the wording were changed > to allow an "operational security" exception to the general > principle of not modifying non-zero IPv6 Flow Labels during transit. > For example, the wording could say that network devices ought > not modify non-zero IPv6 Flow Labels *by default*, leaving it > open for users with particular security concerns to configure > a non-default configuration (i.e. zeroing the Flow Label). > > I request that at least a brief mention of the covert channel > issue be made in the Security Considerations sections of both > draft-ietf-6man-flow-ecmp and draft-ietf-6man-flow-3697bis. > If desired, such mentions could refer to the Gont draft or > to the -3697bis draft for more detailed discussion of that > issue. > > I am troubled by the apparent decision to ignore legitimate > operational security considerations (e.g. about covert channels) > and also the apparent decision to write these documents > in a manner intended to legislate reasonable security measures > (if applicable only in selected deployments) out of existence. > This seems to be a case of the IETF levying deployment > constraints upon users/operators, which is something that the > IETF generally tries to avoid. > > Yours, > > Ran Atkinson > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
