Re: Flow label drafts updated

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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 