From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Tuesday, May 03, 2011 5:58 PM Subject: Re: Flow label drafts updated
> 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. I don't understand this comment. The flow label has always been defined as immutable; the consensus in the WG is to keep that property. So a firewall that overwrites it is unambiguously breaking the standard. [WEG] now it's my turn to be confused by your comment, Brian. I missed this detail of interpretation when reviewing the draft for LC, and I apologize, but I think it's pretty important... >From the 3697bis draft: "There is no way to verify whether a flow label has been modified en route or whether it belongs to a uniform distribution. Therefore, no Internet-wide mechanism can depend mathematically on immutable and uniformly distributed flow labels; they have a "best effort" quality." But it goes on to say: " This specification defines the flow label as immutable once it has been set to a non-zero value. However, implementers are advised that forwarding nodes, especially those acting as domain border devices, might nevertheless be configured to change the flow label value in packets. This is undetectable." My interpretation of the above is that it functionally renders the flow label mutable. If one cannot assume that the flow label will arrive at its destination with the original value intact, nor detect when it has been changed, it is by definition mutable and it's nonsensical to have this discussed in such an ambiguous way in the draft, because no implementer in their right mind is going to try to use this for an application that needs the label to be immutable in all cases. This draft should be correcting the fundamentally flawed assumption that an unprotected field can be immutable. I don't see how Ran's comments would be a different case and (apparently) a different interpretation of the above. I don't recall consensus forming around this idea of immutable, but with asterisks instead of simply acknowledging that regardless of what the standard said before, the label has always been mutable since it's unprotected. However, I've had a couple of gaps where $day_job has taken precedence over IETF lists, so I might have missed a part of that discussion. Apologies if I'm rehashing. Perhaps the chairs would like to offer an interpretation? Wes George
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------