Subject: Re: RFC 3697bis Open issue 9

From: RJ Atkinson <[email-masked]>
Date: Thu, 3 Feb 2011 10:17:12 -0500

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.

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).  

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.

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).

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.

Yours,

Ran Atkinson

---

From: Bob Hinden <[email-masked]>
Date: Thu, 3 Feb 2011 10:07:29 -0800

Ran,

> Joel's comments are well put.

I agree with Joel's comments on negative aspects of remarking flow labels.

> 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.   

> 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?  

> (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

> Label of an arbitrary IPv6 packet will contain values useful for 

Without more evidence, I don't agree.

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 3 Feb 2011 13:41:20 -0500

On 03  Feb 2011, at 13:07 , Bob Hinden wrote:
>  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.

So far as I am aware, no one has suggested not specifying
how the Flow Label field might be used for load balancing.  

What I suggested was distinctly different, namely that some
operational domains are likely to zero that field, either in 
the origin node or as the packet crosses an administrative 
boundary, in order to comply with domain-specific policy.

In turn that means (A) it is unlikely that IPv6 Flow Labels will
reliably be unchanged end-to-end and (B) it is likely that some 
IPv6 packets with zero-filled Flow Label fields will continue 
to be seen on the global public Internet for the forseeable future.

I also suggested that trying to legislate this issue out of existence 
by putting words in an RFC was unlikely to be effective.  Operational
folks in a wide range of organisations routinely configure their 
systems to match local security policies, even when that policy or 
configuration is not consistent with existing RFCs.

Cheers,

Ran

---

From: Steven Blake <[email-masked]>
Date: Thu, 03 Feb 2011 14:54:23 -0400

> as a relatively high-bandwidth covert channel -- due to its size.

 [snip]

> Label of an arbitrary IPv6 packet will contain values useful for

 Would a one-byte covert channel in the flow label be considered a 
 problem?  I.e., if a firewall only zeroed out the most significant 12 
 bits of the flow label, that would still leave 8 random bits for the 
 LAG/ECMP hash key, which is probably more than enough in practice.  The 
 firewall could alternatively choose to recompute the lower 8 bits using 
 5-tuple hash, since presumably it is already digging its way through the 
 packet headers.

 Actually, a firewall could always choose to rewrite the whole flow 
 label with the output of its own hash calculation (or a per-flow cached 
 pseudo-random number), eliminating any covert channel.

 Regards,

 // Steve

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 3 Feb 2011 14:13:41 -0500

On 03  Feb 2011, at 13:54 , Steven Blake wrote:
> The firewall could alternatively choose to recompute the lower 8 bits
> using 5-tuple hash, since presumably it is already digging its way
> through the packet headers.

I think sites with this concern would be comfortable with that approach.

As you say, a site firewall/border-router that is applying a policy
to Flow Label field bits is already rummaging through packet headers
looking at various other stuff, so creating its own replacement 
(full or partial) Flow-Label value is probably not a lot of extra work.

> Actually, a firewall could always choose to rewrite the whole flow label
> with the output of its own hash calculation (or a per-flow cached

Exactly so.

That noted, Joel is quite correct that a larger sized inter-domain
transit/backbone router is not terribly likely to have the ability 
today to regenerate a Flow Label while also forwarding packets 
at wire-speed.

Yours,
Ran

---

From: Bob Hinden <[email-masked]>
Date: Thu, 3 Feb 2011 11:22:15 -0800

Ran,

> how the Flow Label field might be used for load balancing.  

OK, it's good to make that clear.

> to be seen on the global public Internet for the forseeable future.

For sure, but I suspect this will be the case for the foreseeable future due to the time it takes to update existing implementations that don't currently set the flow label.

> configuration is not consistent with existing RFCs.

That's why the current draft says SHOULD.  The usual definition of SHOULD covers the scenario you describe.

Bob

> 
> Cheers,
> 
> Ran
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Feb 2011 11:16:42 +1300

On 2011-02-04 08:22, Bob Hinden wrote:
...
> That's why the current draft says SHOULD.  The usual definition of SHOULD covers the scenario you describe.

Exactly. So does anybody want to propose precise changes to the current
text, which is intended to navigate between the various issues?

We can always add discussion to the rationale document, but IMHO the
normative text needs to be as short as possible while being logically complete.

   Brian