Hi Ran, On 2011-05-10 01:02, RJ Atkinson wrote: > 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."
The authors really need to hear that from more than one person, or to hear from the WG Chairs that it's a consensus, because it goes against several months of discussion. > > 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." Well, others have said 'don't say that', in response to earlier versions with loosely equivalent text, so again the authors need to be told what the consensus is. As Ray Hunter said on another thread, reality suggests that the IETF should recognise the existence of firewalls... so why not be explicit? I suggest squaring this circle by retaining the MUST NOT (which IMHO is the present consensus) but making it clear in the security considerations that there will be exceptions. The problem here is that the RFC 2119 language doesn't provide MUST NOT UNLESS..., which is what we really need. SHOULD NOT is not perceived as strong enough. > > 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. Agreed. Brian > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
