Re: Flow label drafts updated

[RJ Atkinson <[e-mail]>]

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