On 06 May 2011, at 21:23 , Brian E Carpenter wrote: > I'm hard over on a MUST NOT. What we've been arguing with Thomas is really > about > how to express the warning that the flow label might get undetectably changed > by > an on-path device, even though that is against the standard. A node downstream > from the change can't tell that it was changed, whether maliciously or > by a misguided firewall.
Brian, As Wes and others (including me) have been pointing out is that the IPv6 specs have been ambiguous about the Flow Label field for a very long time (i.e. including before this current set of I-Ds). The specs have tried simultaneously both to discourage modification of the Flow Label field (which I believe everyone agrees is strongly desirable in normal circumstances) and simultaneously recognising that the field might be changed (i.e. in some other circumstances). This issue is very far from new. As the AH designer/author, I can say that the reason AH doesn't include the Flow Label field in its integrity checks is that network operators (a term I use to mean *anyone* who operates any network, whether service provider, content provider, home network, enterprise network, educational network, or other network) way back in the early 1990s were clear that in some circumstances the Flow Label field would be changed during transit. The IPv6 WG was comfortable with that at the time. Further, other IETF standards-track specifications (e.g. RFC-2402, Section 3.3.3.1.2.1; RFC-4302, Section 3.3.3.1.2.1) clearly note the IPv6 Flow Label as "mutable". RFC-1886 Section 6 and RFC-2460 Section 6 both require that hosts/routers *that do not support the Flow Label* not modify it, but does NOT require that hosts/routers that do support the Flow Label not modify its value. RFC-4302 specifically notes that RFC-2460 does permit modification of the IPv6 Flow Label. The Security Gateways I've been talking about clearly DO support the Flow Label, so are NOT covered by that prohibition. It is only with RFC-3697 that an attempt is made to prohibit modification of the Flow Label in transit -- but of course there are a number of IPv6 devices deployed that pre-date that specificatio. Further, RFC-3697 does NOT claim to update RFC-2460 (and RFC-2460 does allow modification). So there is an inherent ambiguity in the set of IETF standards-track specifications on this topic. It is also quite clear the IPv6 WG does NOT have some sort of long-standing agreement that this practice should be prohibited; instead the long-standing situation is that change should be strongly discouraged (i.e. SHOULD NOT), but is both expected and tolerated in the (few) situations where it is necessary from an operational security perspective. Your assertion that a firewall modifying the Flow Label field is "misguided" is not technically sound. In some deployment situations, rewriting the Flow Label field (e.g. from some received value which might contain covert information to some different value which the security gateway determines does not contain covert information) is the only technically sound behaviour. Those situations are not numerous, fortunately. I find it curious that you aren't addressing the technical issues that various folks are raising here, instead solely talking about legalistic claims. If you have a concrete technical issue, please put it forward and lets discuss it. It is also wrong to try to separate this concern from Thomas Narten's concern as they are quite closely related and inter-twined. Yours, Ran Atkinson -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
