Hi,
I tried to run the 1.5.0 Beta2 TAHI Selftest on recent Linux kernel.
It fails in the Stateless Address Autoconfiguration section with
6 tests.
These tests are for Duplicate Address Detection (DAD).
They are detect for the Link Local Address a duplicate address on the
network. It seems that our current behavior is to log an message and
do not assign this address.
But the RFC 4862 says:
5.4.5. When Duplicate Address Detection Fails
A tentative address that is determined to be a duplicate as described
above MUST NOT be assigned to an interface, and the node SHOULD log a
system management error.
If the address is a link-local address formed from an interface
identifier based on the hardware address, which is supposed to be
uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
operation on the interface SHOULD be disabled. By disabling IP
operation, the node will then:
- not send any IP packets from the interface,
- silently drop any IP packets received on the interface, and
- not forward any IP packets to the interface (when acting as a
router or processing a packet with a Routing header).
In this case, the IP address duplication probably means duplicate
hardware addresses are in use, and trying to recover from it by
configuring another IP address will not result in a usable network.
In fact, it probably makes things worse by creating problems that are
harder to diagnose than just disabling network operation on the
interface; the user will see a partially working network where some
things work, and other things do not.
On the other hand, if the duplicate link-local address is not formed
from an interface identifier based on the hardware address, which is
supposed to be uniquely assigned, IP operation on the interface MAY
be continued.
So I think we should disable the interface now, if DAD fails on a
hardware based LLA.
--
Karsten Keil
SuSE Labs
From: Neil Horman <nhorman@tuxdriver.com> Date: 2008-01-09 16:19:01
On Wed, Jan 09, 2008 at 04:36:56PM +0100, Karsten Keil wrote:
Hi,
I tried to run the 1.5.0 Beta2 TAHI Selftest on recent Linux kernel.
It fails in the Stateless Address Autoconfiguration section with
6 tests.
These tests are for Duplicate Address Detection (DAD).
They are detect for the Link Local Address a duplicate address on the
network. It seems that our current behavior is to log an message and
do not assign this address.
But the RFC 4862 says:
5.4.5. When Duplicate Address Detection Fails
A tentative address that is determined to be a duplicate as described
above MUST NOT be assigned to an interface, and the node SHOULD log a
system management error.
If the address is a link-local address formed from an interface
identifier based on the hardware address, which is supposed to be
uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
operation on the interface SHOULD be disabled. By disabling IP
operation, the node will then:
- not send any IP packets from the interface,
- silently drop any IP packets received on the interface, and
- not forward any IP packets to the interface (when acting as a
router or processing a packet with a Routing header).
In this case, the IP address duplication probably means duplicate
hardware addresses are in use, and trying to recover from it by
configuring another IP address will not result in a usable network.
In fact, it probably makes things worse by creating problems that are
harder to diagnose than just disabling network operation on the
interface; the user will see a partially working network where some
things work, and other things do not.
On the other hand, if the duplicate link-local address is not formed
from an interface identifier based on the hardware address, which is
supposed to be uniquely assigned, IP operation on the interface MAY
be continued.
So I think we should disable the interface now, if DAD fails on a
hardware based LLA.
Not sure I agree with that. I assume that by disable, you mean that we should
clear the IFF_UP flag? If we do that, and another ip address is assigned to
that interface, then your proposal would discontinue the functionality of those
already established addresses, which would be bad. I could see a DOS scenario
comming out of that as well. Simply send ndisc na's for a recently advertised
address, and you could prevent network communication for an entire system.
Reading the section you reference, we do follow all the MUST requirements, and
we log an error. Given that the disable section is a SHOULD, I think we can at
least be somewhat more restrictive in our implementation. Perhaps we should
just disable the interface iff the failed address is link-local AND there are no
other functional address assigned to the interface.
Neil
--
Karsten Keil
SuSE Labs
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 09, 2008 at 11:17:48AM -0500, Neil Horman wrote:
On Wed, Jan 09, 2008 at 04:36:56PM +0100, Karsten Keil wrote:
quoted
Hi,
I tried to run the 1.5.0 Beta2 TAHI Selftest on recent Linux kernel.
It fails in the Stateless Address Autoconfiguration section with
6 tests.
These tests are for Duplicate Address Detection (DAD).
They are detect for the Link Local Address a duplicate address on the
network. It seems that our current behavior is to log an message and
do not assign this address.
But the RFC 4862 says:
5.4.5. When Duplicate Address Detection Fails
A tentative address that is determined to be a duplicate as described
above MUST NOT be assigned to an interface, and the node SHOULD log a
system management error.
If the address is a link-local address formed from an interface
identifier based on the hardware address, which is supposed to be
uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
operation on the interface SHOULD be disabled. By disabling IP
operation, the node will then:
- not send any IP packets from the interface,
- silently drop any IP packets received on the interface, and
- not forward any IP packets to the interface (when acting as a
router or processing a packet with a Routing header).
In this case, the IP address duplication probably means duplicate
hardware addresses are in use, and trying to recover from it by
configuring another IP address will not result in a usable network.
In fact, it probably makes things worse by creating problems that are
harder to diagnose than just disabling network operation on the
interface; the user will see a partially working network where some
things work, and other things do not.
On the other hand, if the duplicate link-local address is not formed
from an interface identifier based on the hardware address, which is
supposed to be uniquely assigned, IP operation on the interface MAY
be continued.
So I think we should disable the interface now, if DAD fails on a
hardware based LLA.
Not sure I agree with that. I assume that by disable, you mean that we should
clear the IFF_UP flag? If we do that, and another ip address is assigned to
that interface, then your proposal would discontinue the functionality of those
already established addresses, which would be bad. I could see a DOS scenario
comming out of that as well. Simply send ndisc na's for a recently advertised
address, and you could prevent network communication for an entire system.
Reading the section you reference, we do follow all the MUST requirements, and
we log an error. Given that the disable section is a SHOULD, I think we can at
least be somewhat more restrictive in our implementation. Perhaps we should
just disable the interface iff the failed address is link-local AND there are no
other functional address assigned to the interface.
I agree here, but it seems that currently the IPv6 Logo Committee thinks
that it has to be disable the interface to get the IPv6 ready Logo in
future. I already claim that on a discussion at the TAHI users list.
So far I remember a SHOULD in RFC has to interpreted as "You should
implement that in this way, exceptions are only acceptable for a good
reason". Maybe the DOS scenario is such a good reason.
--
Karsten Keil
SuSE Labs
Hi,
On Wed, Jan 09, 2008 at 09:26:53PM +0100, Karsten Keil wrote:
quoted
Reading the section you reference, we do follow all the MUST requirements, and
we log an error. Given that the disable section is a SHOULD, I think we can at
least be somewhat more restrictive in our implementation. Perhaps we should
just disable the interface iff the failed address is link-local AND there are no
other functional address assigned to the interface.
I agree here, but it seems that currently the IPv6 Logo Committee thinks
that it has to be disable the interface to get the IPv6 ready Logo in
future. I already claim that on a discussion at the TAHI users list.
JFYI, here the answer from the TAHI list.
Hi, Karsten.
Thanks for your comments.
I know that it is SHOULD,
but our test tool supports the test specification
published by IPv6 Ready Logo Program <http://www.ipv6ready.org/>,
and basically the test specification supports all of MUST and SHOULD.
You may know,
now IPv6 Ready Logo Committee is also discussing
about the next major revision up of test specification.
RFC 4862 Section 5.4.5 is one of discussing point.
The public review has been over,
but if you have strong concern about it,
I recommend to comment to [off-list ref].
Personally,
I think that mandating this function is the best way.
But vendor's input will really important for them.
Regards,
Yukiyo Akisada
So it would be good if some of the networking experts complain there.
--
Karsten Keil
SuSE Labs
ISDN and VOIP development
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
In article [off-list ref] (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil [off-list ref] says:
So I think we should disable the interface now, if DAD fails on a
hardware based LLA.
I don't want to do this, at least, unconditionally.
Options (not exclusive):
- we could have "enable_ipv6" interface flag and check it in
input/output paths
- we could have "dad_reaction" interface variable and
> 1: disable interface
= 1: disable IPv6
< 0: ignore (as we do now)
--yoshfuji
On Thu, Jan 10, 2008 at 01:40:51AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [off-list ref] (at Thu, 10 Jan 2008 01:38:57 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 [off-list ref] says:
quoted
- we could have "dad_reaction" interface variable and
> 1: disable interface
= 1: disable IPv6
< 0: ignore (as we do now)
Argh, >0, 0 and <0, maybe.
I would like this solution, I had something similar to this in mind after I
discovered the issue.
--
Karsten Keil
SuSE Labs
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
From: Neil Horman <nhorman@tuxdriver.com> Date: 2008-01-09 18:58:39
On Thu, Jan 10, 2008 at 01:38:57AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [off-list ref] (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil [off-list ref] says:
quoted
So I think we should disable the interface now, if DAD fails on a
hardware based LLA.
I don't want to do this, at least, unconditionally.
Options (not exclusive):
- we could have "dad_reaction" interface variable and
> 1: disable interface
= 1: disable IPv6
< 0: ignore (as we do now)
I like the flexibility of this solution, but given that the only part of the RFC
that we're missing on at the moment is that we SHOULD disable the interface on
DAD failure for a link-local address, I would think this scheme would be good:
< 0 : ignore, and del address from interface (current behavior)
= 0 : disable interface for dad failure for a link-local address
> 0 : disable interface for dad failure for any address
Regards
Neil
--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 10, 2008 at 01:38:57AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
quoted
In article [off-list ref] (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil [off-list ref] says:
quoted
So I think we should disable the interface now, if DAD fails on a
hardware based LLA.
I don't want to do this, at least, unconditionally.
Options (not exclusive):
- we could have "dad_reaction" interface variable and
> 1: disable interface
= 1: disable IPv6
< 0: ignore (as we do now)
I like the flexibility of this solution, but given that the only part of the RFC
that we're missing on at the moment is that we SHOULD disable the interface on
DAD failure for a link-local address, I would think this scheme would be good:
< 0 : ignore, and del address from interface (current behavior)
= 0 : disable interface for dad failure for a link-local address
> 0 : disable interface for dad failure for any address
Regards
Neil
Just a friendly reminder that such a scheme should only be
applied to autoconfigured addresses. A manually configured
duplicated address should not bring down the whole interface.
-vlad
From: Neil Horman <nhorman@tuxdriver.com> Date: 2008-01-10 12:26:58
On Wed, Jan 09, 2008 at 04:09:57PM -0500, Vlad Yasevich wrote:
Neil Horman wrote:
quoted
On Thu, Jan 10, 2008 at 01:38:57AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
quoted
In article [off-list ref] (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil [off-list ref] says:
quoted
So I think we should disable the interface now, if DAD fails on a
hardware based LLA.
I don't want to do this, at least, unconditionally.
Options (not exclusive):
- we could have "dad_reaction" interface variable and
> 1: disable interface
= 1: disable IPv6
< 0: ignore (as we do now)
I like the flexibility of this solution, but given that the only part of the RFC
that we're missing on at the moment is that we SHOULD disable the interface on
DAD failure for a link-local address, I would think this scheme would be good:
< 0 : ignore, and del address from interface (current behavior) = 0 :
disable interface for dad failure for a link-local address > 0 : disable
interface for dad failure for any address
Regards
Neil
Just a friendly reminder that such a scheme should only be
applied to autoconfigured addresses. A manually configured
duplicated address should not bring down the whole interface.
I agree, but I think that case would be covered by the default option above
(sysctl < 0).
Neil
If the address is a link-local address formed from an interface
identifier based on the hardware address, which is supposed to be
uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
operation on the interface SHOULD be disabled. By disabling IP
operation, the node will then:
- not send any IP packets from the interface,
- silently drop any IP packets received on the interface, and
- not forward any IP packets to the interface (when acting as a
router or processing a packet with a Routing header).
I question any RFC mandate that shuts down IP communication on a node
because of packets received from remote systems.
If the TAHI test can trigger this, so can a compromised system on your
network and won't that be fun? :-)
In article [off-list ref] (at Wed, 09 Jan 2008 15:32:12 -0800 (PST)), David Miller [off-list ref] says:
I question any RFC mandate that shuts down IP communication on a node
because of packets received from remote systems.
RFC4862 tell us that we SHOULD disable IP communication.
(IP means IPv6 here; IPv4 is out of scope.)
In IETF term, a SHOULD is almost a MUST. We are required to follow
unless we have very good reason to ignore it.
If the TAHI test can trigger this, so can a compromised system on your
network and won't that be fun? :-)
So, I know the specification, but I have ignored it.
I think it is fine to implent in some way, but I do think we must have
a switch not to do this.
--yoshfuji
In article [off-list ref] (at Wed, 09 Jan 2008 15:32:12 -0800 (PST)), David Miller [off-list ref] says:
quoted
I question any RFC mandate that shuts down IP communication on a node
because of packets received from remote systems.
RFC4862 tell us that we SHOULD disable IP communication.
(IP means IPv6 here; IPv4 is out of scope.)
In IETF term, a SHOULD is almost a MUST. We are required to follow
unless we have very good reason to ignore it.
A DoS by definition is a very good reason.
quoted
If the TAHI test can trigger this, so can a compromised system on your
network and won't that be fun? :-)
So, I know the specification, but I have ignored it.
I think it is fine to implent in some way, but I do think we must have
a switch not to do this.
Because of the above, the existing behavior must still stay the
default. I hope this is your plan.
By default Linux will not implement this SHOULD, it's a security
issue.
I more and more do not like these conformance tests, they leave no
room whatsoever for handling bugs or ill-specified features in the
specification.
In article [off-list ref] (at Wed, 09 Jan 2008 15:55:44 -0800 (PST)), David Miller [off-list ref] says:
Because of the above, the existing behavior must still stay the
default. I hope this is your plan.
By default Linux will not implement this SHOULD, it's a security
issue.
Yes so far, though we may have more things to consider.
--yoshfuji
If the address is a link-local address formed from an interface
identifier based on the hardware address, which is supposed to be
uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
operation on the interface SHOULD be disabled. By disabling IP
operation, the node will then:
- not send any IP packets from the interface,
- silently drop any IP packets received on the interface, and
- not forward any IP packets to the interface (when acting as a
router or processing a packet with a Routing header).
I question any RFC mandate that shuts down IP communication on a node
because of packets received from remote systems.
If the TAHI test can trigger this, so can a compromised system on your
network and won't that be fun? :-)
I agree, but on the other side, a interface with a real duplicate HW address
sending packets on the network can also cause very serious problems, and
maybe is not so easy to detect as a system where the interface never come
up because of this. So maybe it makes sense to implement it as option, not
as default.
And the DOS scenario is already here, also without disabling IP completely,
since you can deny any IPv6 address assignments with faked DAD pakets.
--
Karsten Keil
SuSE Labs
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)