On 2011-05-07 23:33, RJ Atkinson wrote:
> 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).
IMHO, RFC 3697 is quite clear that the flow label must not be modified,
but quite unhelpful in discussing how to deal with the fact that it
isn't checksummed.
What RFC 2460 says about the flow label is pretty useless on all counts,
which is why we wrote RFC 3697 in the first place.
>
> 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.
I take your word for it, but when the WG did RFC 3697 in 2003/2004, there was
strong consensus for the immutability rule.
>
> 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".
There was a thread about this on the IPv6 WG list in September 2004,
under the subject "AH and flow label". The conclusion was to continue
to leave the flow label out of the ICV calculation in the AH update
that became RFC 4302, although it was by then clearly specified as
immutable by RFC 3697.
It seemed that the goal was to be backwards compatible with RFC 2402.
The terminology "immutable" and "mutable" was the only way in that RFC
to tag header fields as included or excluded in the ICV calculation.
So an immutable field (under RFC 3697) is labelled mutable in RFC 4302.
Duh!
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.
I missed that. It's a bug, since the correct normative reference at that
time was RFC 3967.
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).
3697 clearly should have been tagged as formally updating 2460.
3697bis will definitely fix this.
But it's really playing with words to assert that a firewall which
chooses to overwrite the field is "supporting" it in the sense
intended by the phrase "Hosts or routers that do not support the
functions of the Flow Label field...".
> 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;
IPv6 and its successor 6MAN have been very clear on this since 2003/4
when RFC 3697 was developed.
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.
So far, the guidance from the WG has been for a MUST NOT. Obviously,
if the consensus changes, so will the draft.
> 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.
"Misguided" was an emotional choice of word, for which I apologise.
I agree that there should be a discussion of covert channels
in the Secutity Considerations of 3697bis. That is a clear omission.
>
> I find it curious that you aren't addressing the technical issues
> that various folks are raising here, instead solely talking about
> legalistic claims.
What I'm talking about is what I think we heard from the WG over the
past many months.
If you have a concrete technical issue,
> please put it forward and lets discuss it.
The technical issue is that load balancing based on flow label values
won't work properly if middleboxes (or attackers) change the values
arbitrarily.
It is also wrong to try
> to separate this concern from Thomas Narten's concern as they are
> quite closely related and inter-twined.
Thomas has argued that if the label MUST NOT be changed, we should
remove any suggestion of cases in which it's OK to change it. Followed
to its logical conclusion, that means it's not OK for a firewall to
change it.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
