On 08 May 2011, at 19:06 , Brian E Carpenter wrote:
> Maybe it's just the use of the word "immutable" that is causing the
> problem here, because it implies something that physically isn't true.
I think that is a very very important part, possibly the
central element, of this discussion. This is a large part
of why Wes's concerns, Fernando's concerns, and my concerns
are in fact deeply intertwined with Thomas Narten's concerns.
IMHO, trying to prohibit change in the Flow Label is about
as sensible as the USA's attempt last century to prohibit all
consumption of alcohol. (For folks outside the USA, that attempt
failed miserably and within N years "prohibition" was repealed.)
A much more reasonable approach would be to say (edit to taste):
"The Flow Label SHOULD NOT be changed in transit."
probably coupled with (also, edit to taste):
"If the Flow Label is changed in transit (e.g. due to
operational security considerations), then the Flow Label
should be changed to a value that complies with the
mathematical requirements for use in load balancing."
A security gateway is by definition trusted. So it could take
a non-zero value that potential contains hidden information and
replace it with some different non-zero value that the gateway
knows does not contain hidden information. So long as both
values comply with the mathematical requirements for load-balancing,
there is no adverse impact on the operational goals of the current
drafts. It would be reasonable to prohibit taking a non-zero value
and making it zero, IMHO. Although deployed systems are not likely
to change their behaviour, over time such systems might get upgraded
to rewrite in a way that both meets security requirements and also
meets the load-balancing objectives.
Yours,
Ran
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
