Ran, On Feb 3, 2011, at 7:17 AM, RJ Atkinson wrote:
> On 31 Jan 2011 at 09:17:47 -0500, Joel Halpern wrote: >> Several of these comments have a common theme of requiring domains >> to remark flow-labels on ingress. While we have agreed to allow >> remarking of packets with 0 values in their flow label, expecting >> repeated remarking seems to me a very bad idea. Basically, if we do that, >> then I expect that most routers will simply assume that the flow label >> is useless, since we can not expect peering scale routers to remark >> the flow label of packets based on deep packet inspection. Also, >> in many cases, as described in other documents, such re-marking >> is effectively impossible. > > Joel's comments are well put. I agree with Joel's comments on negative aspects of remarking flow labels. > > That noted, everyone interested in the Flow Label issue needs > to keep in mind that various operational domains (e.g. sites, > organisations, providers) have various domain-specific and > site-specific security policies that preclude end-to-end > Flow Label values. > > In particular, a number of domains connected to the public Internet, > including a number of commercial firms, are concerned about use of > "covert channels" by their adversaries (e.g. to steal IPR, to probe > interior network segments). It would be helpful if someone could come forward who has this requirement. I could beleive there are some users who have this requirement, I think it is a very small subset. I remain skeptical that the flow label field is really an effective "covert channel". There are so many better ways of insider attacks available than sending it in the flow label field. This seems to me to be more theoretical than real to me. I did some searches on the web for IPv6 covert channels. Most of what I found was talking about not filtering any IPv6 traffic, or using things like ICMPv6 echo request/reply. Further, why doesn't the fragment ID in IPv4 cause a similar problem? It's 16 bits, vs. the flow label's 20 bits. > While most (all ?) useful communications protocols have at least > some low-bandwidth covert channels, the IPv6 Flow Label stands out > as a relatively high-bandwidth covert channel -- due to its size. 20 bits per packet. At 100 packets / second that 2K bps. Is that high bandwidth? > > Packets entering or leaving a domain with such a security policy > very likely will have their IPv6 Flow Label either zeroed or otherwise > overwritten with new values upon ingress or egress. I understand that > such capabilities commonly exist in currently deployed commercially > available firewall products. I'm further told that the larger > sized commercial firewalls have hardware (e.g. ASICs) that can > zero or remark IPv6 Flow Label values at interestingly high speeds > (e.g. at least wire-speed for a 1 GigE interface, possibly faster). They may be available in some firewalls, but the one I am familiar with does not do this. I also don't see anything like this in PF (an open source firewall that I have used). Can you point to some product specs? A determined insider has an almost infinite number of communication paths available. They don't even need Internet access, let alone IPv6. I don't think we should limit the use of the flow label for load balancing due to a concern about covert channels using the flow label. Bob > > Similarly, organisations operating such domains do NOT want their > end systems putting non-zero bits into the IPv6 Flow Label during > packet origination, as that is a particularly interesting high > speed way to covertly export data from such end systems. One > imagines that sysctl() or similar knobs might be used by some > system administrators to disable generation of non-zero IPv6 > Flow Labels within the originating nodes of a given domain. > > Kindly note that I'm merely reporting what I understand to be the > case in an interesting number of cases. I'm not advocating any > particular behaviour on the part of any enterprise/ISP/other > network operator. Also note that the IETF normally levies > requirements upon device/protocol implementers, but does not > normally levy requirements upon enterprise/ISP/other network > operators. In any event, one imagines the local security policy > will de facto take precedence over what any RFC says, within > a given domain, should an RFC contradict local security policy. > > When one intersects Joel's comments above and my observations > above, it is not obvious to me that an arbitrary router somewhere > in the global Internet reasonably could expect that the IPv6 Flow > Label of an arbitrary IPv6 packet will contain values useful for > LAG, SLB, etc. Without more evidence, I don't agree. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
