On 9 Sep 2010, at 06:49, Mikael Abrahamsson wrote:
In real life, ISPs consider DSCP as one thing they have the right to change
(along with TTL) in transit. I can imagine the flow label being considered
the same thing regardless of what the standard says.
The interesting thing in the
Hi Iljitsch,
Le 8 sept. 2010 à 10:44, Iljitsch van Beijnum a écrit :
...
There is work going on on creating multipath TCP where a TCP flow is split
into subflows which take different paths. (See the MPTCP wg.) Currently, it
is assumed that the paths are defined by the source/destination
Mikael,
On Sep 8, 2010, at 23:49 MDT, Mikael Abrahamsson wrote:
On Thu, 9 Sep 2010, Brian E Carpenter wrote:
If we do agree on this, it's very helpful, because it guides all further
decisions. For example, it allows us to see that the label is immutable on a
best effort basis, rather than
On 9 sep 2010, at 15:04, Rémi Després wrote:
There is work going on on creating multipath TCP where a TCP flow is split
into subflows which take different paths. (See the MPTCP wg.) Currently, it
is assumed that the paths are defined by the source/destination address
pairs, but there are
Le 9 sept. 2010 à 16:38, Iljitsch van Beijnum a écrit :
On 9 sep 2010, at 15:04, Rémi Després wrote:
...
Subflows of MPTCP have different 5-tuples.
They should be treated as different flows as far as load balancing is
concerned.
That depends on the flavor of MPTCP.
Certainly with the
On Thu, 9 Sep 2010, Fernando Gont wrote:
Mikael Abrahamsson wrote:
Last I checked, the standards said that if precedence/dscp changed, the
host should reset the session (correct me if I'm wrong, I don't really
have time to check it right now).
You're right. And it doesn't make sense. See
Tim,
On Sep 9, 2010, at 05:05 MDT, Tim Chown wrote:
On 9 Sep 2010, at 06:49, Mikael Abrahamsson wrote:
In real life, ISPs consider DSCP as one thing they have the right to change
(along with TTL) in transit. I can imagine the flow label being considered
the same thing regardless of what
On 2010-09-10 05:51, Mikael Abrahamsson wrote:
On Thu, 9 Sep 2010, Fernando Gont wrote:
Mikael Abrahamsson wrote:
Last I checked, the standards said that if precedence/dscp changed, the
host should reset the session (correct me if I'm wrong, I don't really
have time to check it right now).
On Sep 8, 2010, at 1:02 PM, Christopher Morrow wrote:
this all gets 'crazy', I suppose if we wanted to route on flow-label
not destination-ip-address this might happen, but ... that seems
'crazy' as I said before :) since not everyone would be using the
flow-label (maybe) and inconsistent
On 8 sep 2010, at 3:18, Brian E Carpenter wrote:
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
Le 8 sept. 2010 à 03:18, Brian E Carpenter a écrit :
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
Le 8 sept. 2010 à 05:38, Brian E Carpenter a écrit :
... Let's assume you're using it for ECMP or LAG. You're hashing
the flow label as part of the ECMP/LAG hash. Someone figures out
how to compute a flow label for each packet arriving on your 10GB
line that will bias your hash, and therefore
On Wed, Sep 8, 2010 at 5:23 AM, Rémi Després remi.desp...@free.fr wrote:
Le 8 sept. 2010 à 03:18, Brian E Carpenter a écrit :
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
On Wed, Sep 8, 2010 at 1:37 AM, Fred Baker f...@cisco.com wrote:
On Sep 8, 2010, at 1:02 PM, Christopher Morrow wrote:
this all gets 'crazy', I suppose if we wanted to route on flow-label
not destination-ip-address this might happen, but ... that seems
'crazy' as I said before :) since not
Le 8 sept. 2010 à 14:52, Christopher Morrow a écrit :
On Wed, Sep 8, 2010 at 5:23 AM, Rémi Després remi.desp...@free.fr wrote:
Le 8 sept. 2010 à 03:18, Brian E Carpenter a écrit :
Hi,
The authors of draft-carpenter-6man-flow-update (now also
including Shane Amante) are working on a
On Wed, Sep 8, 2010 at 8:59 AM, Rémi Després remi.desp...@free.fr wrote:
Le 8 sept. 2010 à 14:52, Christopher Morrow a écrit :
On Wed, Sep 8, 2010 at 5:23 AM, Rémi Després remi.desp...@free.fr wrote:
Le 8 sept. 2010 à 03:18, Brian E Carpenter a écrit :
Thus
some firewalls *will* decide
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
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
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian E
Carpenter
Sent: Tuesday, September 07, 2010 9:19 PM
To: 6man
Subject: Flow label (im)mutability
Hi,
The authors of draft-carpenter-6man-flow-update (now also
including Shane Amante) are
Hi, Brian,
That presumably depends on the use case. The idea is that someone
figures out what flow label values will screw you, and sets such
values. Let's assume you're using it for ECMP or LAG. You're hashing
the flow label as part of the ECMP/LAG hash. Someone figures out
how to compute a
Hi, Iljitsch,
There is currently no writeup of how to use the flow label for ECMP.
And as far as I can tell there are no implementations of this either.
Which is a real shame.
There are a few proposals on how to set it (e.g., Blake's and mine). --
This could be a good way to start.
- we
Brian E Carpenter brian.e.carpen...@gmail.com writes:
what's the threat if it changes in flight? multiple times even?
That presumably depends on the use case. The idea is that someone
figures out what flow label values will screw you, and sets such
values.
And exactly how is this is
Thomas Narten wrote:
Brian E Carpenter brian.e.carpen...@gmail.com writes:
what's the threat if it changes in flight? multiple times even?
That presumably depends on the use case. The idea is that someone
figures out what flow label values will screw you, and sets such
values.
And
Christopher Morrow wrote:
The consequence could be that a FL:
- SHOULD be set by the packet source to a value that generally differs from
a flow to another (e.g. a 5-tuple hash)
- MAY be reset to zero in intermediate nodes, but only for security reasons
clarifying question: only for
Hi, Steven,
FWIW, covering the FL in a header/transport checksum would not guarantee
immutability, since a firewall could always re-calculate either of these.
There are already a variety of covert channels available (e.g., packet
size, packet timing, DSCP, hop count), so I wouldn't lose
Hi, Steven,
FWIW, covering the FL in a header/transport checksum would not guarantee
immutability, since a firewall could always re-calculate either of these.
There are already a variety of covert channels available (e.g., packet
size, packet timing, DSCP, hop count), so I wouldn't lose
On 8 sep 2010, at 19:43, Fernando Gont wrote:
- we shouldn't lock down the flow label such that only one flow label
per flow is allowed because this would impede future innovation
The only problem with this is that if you allow a given flow to use
multiple flows, the flow-label reuse
Thanks for all the discussion. Just commenting on a few points:
On 2010-09-09 08:51, Iljitsch van Beijnum wrote:
...
Remember, the flow label is an optimization, use it if it's
helpful, ignore it otherwise.
I wonder if we all agree on this? I do, but people who want to
encode specific
Brian:
Joel reminds me, in private email, that nobody seems to be commenting on you
original question, which has to do with covert channels and whether that should
affect the discussion of flow labels.
Here's a covert channel for you. I was at an agency last year that uses
specialized mail
Hi, Brian,
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
On Thu, 9 Sep 2010, Brian E Carpenter wrote:
If we do agree on this, it's very helpful, because it guides all further
decisions. For example, it allows us to see that the label is immutable
on a best effort basis, rather than mathematically immutable. So we
ccould say both that forwarding
On Thu, 9 Sep 2010, Fred Baker wrote:
I think the covert channel question is a red herring. Yes, creative
people can do creative things. And the point is...?
I think the lesson is that security minded people (the same people who
wants to filter all ICMP because ICMP is always evil to them),
While there may be a few firewalls that will do whatever they think they
need to in order to shut down covert channels, I do not see that as a
significant factor. I imagine most devices will not do so, since it
does represent a meaningful threat to the site being protected.
(There are other
That was supposed to read since it does NOT represent a meaningful threat.
Joel
On 9/7/2010 9:32 PM, Joel M. Halpern wrote:
While there may be a few firewalls that will do whatever they think they
need to in order to shut down covert channels, I do not see that as a
significant factor. I
On Tue, Sep 7, 2010 at 9:18 PM, 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
Below...
On 2010-09-08 14:44, Christopher Morrow wrote:
On Tue, Sep 7, 2010 at 9:18 PM, 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
On Sep 8, 2010, at 11:44 AM, Christopher Morrow wrote:
On Tue, Sep 7, 2010 at 9:18 PM, Brian E Carpenter
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.
Anything that cannot be
On Sep 8, 2010, at 12:38 PM, Brian E Carpenter wrote:
The idea is that someone
figures out what flow label values will screw you
In the model I proposed, the network the packet is in, as with the DSCP, is in
control of the flow label value.
On Tue, Sep 7, 2010 at 11:38 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
Below...
On 2010-09-08 14:44, Christopher Morrow wrote:
On Tue, Sep 7, 2010 at 9:18 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
Hi,
The authors of draft-carpenter-6man-flow-update (now also
On Tue, Sep 7, 2010 at 11:48 PM, Fred Baker f...@cisco.com wrote:
On Sep 8, 2010, at 11:44 AM, Christopher Morrow wrote:
On Tue, Sep 7, 2010 at 9:18 PM, Brian E Carpenter
If this is correct, it is futile to assert that the flow label
MUST be delivered unchanged to the destination, because we
40 matches
Mail list logo
