Linux IPv6 DAD not full conform to RFC 4862 ?

Linux IPv6 DAD not full conform to RFC 4862 ?

[Karsten Keil]

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

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[Neil Horman]

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

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[Karsten Keil]

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

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[Karsten Keil]

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 <ipv6ready-info@ipv6ready.org>.

    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)

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20080109153656.GA16962@pingi.kke.suse.de> (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil <kkeil@suse.de> 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

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20080110.013857.37616214.yoshfuji@linux-ipv6.org> (at Thu, 10 Jan 2008 01:38:57 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> 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

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[Karsten Keil]

On Thu, Jan 10, 2008 at 01:40:51AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <20080110.013857.37616214.yoshfuji@linux-ipv6.org> (at Thu, 10 Jan 2008 01:38:57 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> 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)

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[Neil Horman]

On Thu, Jan 10, 2008 at 01:38:57AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <20080109153656.GA16962@pingi.kke.suse.de> (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil <kkeil@suse.de> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[Vlad Yasevich]

Neil Horman wrote:
> On Thu, Jan 10, 2008 at 01:38:57AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
>> In article <20080109153656.GA16962@pingi.kke.suse.de> (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil <kkeil@suse.de> 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

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[Neil Horman]

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 <20080109153656.GA16962@pingi.kke.suse.de> (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten Keil <kkeil@suse.de> 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.
>

I agree, but I think that case would be covered by the default option above
(sysctl < 0).

Neil

> -vlad

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[David Miller]

From: Karsten Keil <kkeil@suse.de>
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? :-)

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20080109.153212.144388472.davem@davemloft.net> (at Wed, 09 Jan 2008 15:32:12 -0800 (PST)), David Miller <davem@davemloft.net> 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

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[David Miller]

From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Date: Thu, 10 Jan 2008 08:46:55 +0900 (JST)

> In article <20080109.153212.144388472.davem@davemloft.net> (at Wed, 09 Jan 2008 15:32:12 -0800 (PST)), David Miller <davem@davemloft.net> 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.

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20080109.155544.136768603.davem@davemloft.net> (at Wed, 09 Jan 2008 15:55:44 -0800 (PST)), David Miller <davem@davemloft.net> 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

Re: Linux IPv6 DAD not full conform to RFC 4862 ?

[Karsten Keil]

On Wed, Jan 09, 2008 at 03:32:12PM -0800, David Miller wrote:
> From: Karsten Keil <kkeil@suse.de>
> 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)