Re: Linux IPv6 DAD not full conform to RFC 4862 ?
Hi, On Wed, Jan 09, 2008 at 09:26:53PM +0100, Karsten Keil wrote: 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 [EMAIL PROTECTED]. 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) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
On Wed, Jan 09, 2008 at 03:32:12PM -0800, David Miller wrote: From: Karsten Keil [EMAIL PROTECTED] Date: Wed, 9 Jan 2008 16:36:56 +0100 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) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
On Wed, Jan 09, 2008 at 04:09:57PM -0500, Vlad Yasevich wrote: Neil Horman wrote: On Thu, Jan 10, 2008 at 01:38:57AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: In article [EMAIL PROTECTED] (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil [EMAIL PROTECTED] 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 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 address0 : 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 -vlad -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
In article [EMAIL PROTECTED] (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil [EMAIL PROTECTED] 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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
In article [EMAIL PROTECTED] (at Thu, 10 Jan 2008 01:38:57 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] says: - 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. --yoshfuji -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
On Thu, Jan 10, 2008 at 01:38:57AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: In article [EMAIL PROTECTED] (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil [EMAIL PROTECTED] 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 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
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: 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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
On Thu, Jan 10, 2008 at 01:40:51AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: In article [EMAIL PROTECTED] (at Thu, 10 Jan 2008 01:38:57 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] says: - 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) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
Neil Horman wrote: On Thu, Jan 10, 2008 at 01:38:57AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: In article [EMAIL PROTECTED] (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil [EMAIL PROTECTED] 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 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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
From: Karsten Keil [EMAIL PROTECTED] Date: Wed, 9 Jan 2008 16:36:56 +0100 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? :-) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
In article [EMAIL PROTECTED] (at Wed, 09 Jan 2008 15:32:12 -0800 (PST)), David Miller [EMAIL PROTECTED] 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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Thu, 10 Jan 2008 08:46:55 +0900 (JST) In article [EMAIL PROTECTED] (at Wed, 09 Jan 2008 15:32:12 -0800 (PST)), David Miller [EMAIL PROTECTED] 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. A DoS by definition is a very good reason. 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. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux IPv6 DAD not full conform to RFC 4862 ?
In article [EMAIL PROTECTED] (at Wed, 09 Jan 2008 15:55:44 -0800 (PST)), David Miller [EMAIL PROTECTED] 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 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
