Brian, Steve, On Sep 8, 2010, at 08:40 MDT, Steven Blake wrote: > On Wed, 08 Sep 2010 13:18:41 +1200, Brian E Carpenter > <brian.e.carpen...@gmail.com> wrote: > >> Hi, >> >> The authors of draft-carpenter-6man-flow-update (now also >> including Shane Amante) are working on a new version. One >> fundamental issue that has come up is about the (lack of) >> security properties of the flow label. The most brutal >> expression of this is: >> >> The flow label field is always unprotected (no IP header >> checksum, not included in transport checksums, not included in >> IPsec checksum). It cannot be verified and can be used as a >> covert channel, so it will never pass a security analysis. Thus >> some firewalls *will* decide to clear it, whatever the IETF >> wants. This is inevitable, for exactly the same reason that the >> diffserv code point is rewriteable at domain boundaries. >> >> If this is correct, it is futile to assert that the flow label >> MUST be delivered unchanged to the destination, because we >> cannot rely on this in the real world. >> >> Are we ready to accept this analysis? > > FWIW, covering the FL in a header/transport checksum would not guarantee > immutability, since a firewall could always re-calculate either of these.
Good point. However, a firewall *could* calculate a (pseudo-header) checksum (inclusive of the recv'd flow-label, which is not specified today) to verify that the received flow-label is "intact". Of course, this doesn't guarantee that a middlebox/MiTM somewhere in the path didn't alter the flow-label and recalculate + replace the pseudo-header checksum. Further, your point above is still completely valid that a legitimate firewall (or, more generally, middlebox) can rewrite the FL and recalculate the checksum and forward it on to an internal host and the internal host would be none the wiser. IMHO, that would be unfortunate, however the extra effort in changing the FL and recalculating the pseudo-header checksum doesn't seem worth it for mainstream firewall vendors or, more importantly, FW administrators. > There are already a variety of covert channels available (e.g., packet > size, packet timing, DSCP, hop count), so I wouldn't lose sleep about the > FL adding an additional one. +1. I would add two points: 1) If FW administrators are that paranoid about covert channels, they are (or, should be) using IPSec encryption to avoid potential tampering with [inner/tunneled] packets in the first place -- or, disconnect from the Internet. :) 2) Assuming something like draft-gont-6man-flowlabel-security-00 and/or draft-blake-ipv6-flow-label-nonce-02 were eventually to be adopted, the benefits of those proposals in preventing/reducing off-path attacks would substantially outweigh (ridiculous) beliefs that the FL could be used as a covert channel. -shane -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
