On 09/07/2010 06:38 AM, JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) wrote:
5. Creating an alternative to DHCPv6 ?
One SLAAC is defined to do functionality similar to DHCP (including
per host prefixes/options) how long before options are added so SLAAC
becomes an alternative to DHCPv6 ?
This is
Hi, folks,
FYI.
Thanks!
Kind regards,
Fernando
Original Message
Subject: New Version Notification for draft-gont-6man-teredo-loops-00
Date: Wed, 8 Sep 2010 00:15:31 -0700 (PDT)
From: IETF I-D Submission Tool idsubmiss...@ietf.org
To: ferna...@gont.com.ar
A new version
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 Thu, 26 Aug 2010 09:20:45 -0400
Thomas Narten nar...@us.ibm.com wrote:
Suresh,
Suresh Krishnan suresh.krish...@ericsson.com writes:
The nodes attached to different subscriber lines cannot directly send
packets to each other. They need to talk through the edge router.
How is this
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
Hi Shree,
Thanks for the comments. Please find responses inline.
On 10-09-07 09:38 AM, JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) wrote:
Suresh,
One of the main challenge in implementing the model proposed by the draft
is that edge router has no reliable indication if a host (once it has sent
Hi Doug,
On 10-09-08 02:02 AM, Doug Barton wrote:
On 09/07/2010 06:38 AM, JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) wrote:
5. Creating an alternative to DHCPv6 ?
One SLAAC is defined to do functionality similar to DHCP (including
per host prefixes/options) how long before options are added so
Hi Mark,
On 10-09-08 05:50 AM, Mark Smith wrote:
On Thu, 26 Aug 2010 09:20:45 -0400
Thomas Narten nar...@us.ibm.com wrote:
Suresh,
Suresh Krishnan suresh.krish...@ericsson.com writes:
The nodes attached to different subscriber lines cannot directly send
packets to each other. They need to
Nit: seems unlikely to me you will have any XP devices running IPv6-only; if my
understanding of the situation is correct, such a device requires manual
installation of the IPv6 stack and still requires IPv4 for DNS.
- Ralph
On Sep 8, 2010, at 5:36 PM 9/8/10, Suresh Krishnan wrote:
Hi Doug,
Hi Suresh,
Please see two comments below:
Suresh Krishnan wrote:
Hi Shree,
Thanks for the comments. Please find responses inline.
On 10-09-07 09:38 AM, JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) wrote:
Suresh,
One of the main challenge in implementing the model proposed by the
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
Steve,
On Sep 7, 2010, at 14:17 MDT, Steven Blake wrote:
On Tue, 7 Sep 2010 13:58:21 -0600, Shane Amante sh...@castlepoint.net
wrote:
Hi Fernando,
I have a question on:
http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00
Unless I misunderstand something, you're proposing
Ralph,
I use IPv6 in XP so I can confirm your suspicion on both counts.
IPv6-only is a non-starter for XP.
Suresh,
I understand your goals quite well, which is why I'm opposed to the
adoption of the draft. :) Since practically Day 1 of the IPv6 effort
there has been a movement to make
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
Doug, I am confused by your comments.
Let me describe how I understand the situation. We claimed, when we
crafted IPv6, that hosts did not need to use DHCP for address
assignment. As such, many host stacks did not use DHCP for address
assignment.
Now, operators wanted to offer IPv6
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
Your message is very carefully crafted rhetorically, for which I credit
you with many style points. In terms of standards development less so,
but I'll take everything you say here at face value just in case.
On 09/08/2010 11:01 AM, Joel M. Halpern wrote:
Doug, I am confused by your comments.
Now, operators wanted to offer IPv6 service. I hope we think that is a
good thing. For residential, they looked at what they could count on
from the hosts. And some of them concluded that they could not count on
DHCP, so they designed an architecture around SLAAC. In other words,
they
Hi, Shane,
With that said, I don't think this algorithm is necessarily ideal.
The FL value for any two flows from a src_addr, dst_addr pair may
only vary by a few bits, so if a switch/router uses a poor hash
algorithm for LAG/ECMP, you may not get a good load spread.
Agreed, I share your
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
The question of whether DHCP should be used to supplement SLAAC when
SLAAC is used for address assignment, woudl seem to be a separate
question. In, for example, the SAVI work, we have been told repeatedly
by folks deploying IPv6 that they have to be able to use SLAAC for
address assignment.
Joel - only some operators have decided that they need to allow for the corner
case of an IPv6-capable device with no DHCPv6 connected directly to the SP
network. CableLabs took the approach of mandating DHCPv6 for any device
connected to a cable SP network; the expectation being that a high
On 9/8/2010 11:25 AM, Joel M. Halpern wrote:
The question of whether DHCP should be used to supplement SLAAC when
SLAAC is used for address assignment, woudl seem to be a separate
question.
I think that's part of what the WG needs to decide, which is why I (and
now others) have voiced an
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
RAs/SLAAC work very well when RAs can be multicast to *all* nodes on a
link, and *all* nodes receive exactly the same information about
prefixes and SLAAC. I.e, your normal subnet model.
What BBF is proposing to do, is to use RAs/SLAAC where each customer
node (i.e, each node on the access
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
Hi Ralph,
On 10-09-08 12:17 PM, Ralph Droms wrote:
Nit: seems unlikely to me you will have any XP devices running IPv6-only; if my
understanding of the situation is correct, such a device requires manual
installation of the IPv6 stack and still requires IPv4 for DNS.
You are absolutely
Hi Julien,
On 10-09-08 12:32 PM, Laganier, Julien wrote:
Hi Suresh,
Please see two comments below:
Suresh Krishnan wrote:
Hi Shree,
Thanks for the comments. Please find responses inline.
On 10-09-07 09:38 AM, JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) wrote:
Suresh,
One of the main
Hi Doug,
On 10-09-08 02:16 PM, Doug Barton wrote:
Meanwhile, please provide examples of any OS with greater than 5% market
share that is capable of v6-only operation without the ability to do
DHCPv6.
I don't think anybody here claimed IPv6-only operation. The BBF network
in question is
Sending periodic RAs with the PIO does not help with the two problems that
were pointed out:
- the network does not necessarily know when a host attaches, because the
host may timeout sending RSs before the link layer is available to carry
these RS's up to the node assigning a prefix. As a
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
Suresh Krishnan wrote:
You are absolutely right. The XP devices are SLAAC-only for IPv6 as I
said, but they are dual-stacked. So even in the absence of IPv6
connectivity they will still have IPv4 connectivity.
From my perspective, I find this situation to be fundamentally intolerable,
but
On Wed, 8 Sep 2010 11:45:34 -0400
Suresh Krishnan suresh.krish...@ericsson.com wrote:
Hi Mark,
On 10-09-08 05:50 AM, Mark Smith wrote:
On Thu, 26 Aug 2010 09:20:45 -0400
Thomas Narten nar...@us.ibm.com wrote:
Suresh,
Suresh Krishnan suresh.krish...@ericsson.com writes:
The
On 2010-09-09 06:18, sth...@nethelp.no wrote:
Now, operators wanted to offer IPv6 service. I hope we think that is a
good thing. For residential, they looked at what they could count on
from the hosts. And some of them concluded that they could not count on
DHCP, so they designed an
Hi Fernando,
On Sep 8, 2010, at 12:18 MDT, Fernando Gont wrote:
Hi, Shane,
With that said, I don't think this algorithm is necessarily ideal.
The FL value for any two flows from a src_addr, dst_addr pair may
only vary by a few bits, so if a switch/router uses a poor hash
algorithm for
Hi, Shane,
I respectfully disagree that the hash provides the randomness
suitable for a flow-label to be used as an input-key for flow-based
load-balancing. In your draft, you've defined the calculation of a
Flow Label value as follows: Flow Label = counter + F(Source Address,
Destination
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
Thomas Narten wrote:
[...]
Joel M. Halpern j...@joelhalpern.com writes:
[...]
Now, operators wanted to offer IPv6 service. I hope we think that is a
good thing. For residential, they looked at what they could count on
from the hosts. And some of them concluded that they could
On Wed, 2010-09-08 at 10:29 -0700, Doug Barton wrote:
I use IPv6 in XP so I can confirm your suspicion on both counts.
IPv6-only is a non-starter for XP.
You do need IPv6 and IPv4 on the XP host, but the host can exist in an
IPv6-only network if you put an IPv6-capable nameserver on the host
Hello,
As far as I understand, the attack in §2.1 requires that the victim processes
an IPv4 packets whereby both source and destination are equal to a local
assigned address. Any sane IPv4 stack will reject such a packet, unless it
comes from the loop back.
The user (or 'root') could
On Wed, 2010-09-08 at 11:22 -0600, Shane Amante wrote:
Steve,
On Sep 7, 2010, at 14:17 MDT, Steven Blake wrote:
On Tue, 7 Sep 2010 13:58:21 -0600, Shane Amante sh...@castlepoint.net
wrote:
[snip]
With that said, I don't think this algorithm is necessarily ideal. The FL
value for
On Thu, 9 Sep 2010, Brian E Carpenter wrote:
I can't see why that would be a problem for an operator who uses DHCPv6
as their supported mechanism.
I'm sure there are a lot in the IETF that agrees with you that they don't
understand why it's a problem, because the IETF has historically been
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),
56 matches
Mail list logo
