netdev - Re: Section 4 No. 9,10 Failed was occurred by IPv6 Ready Logo Conformance Test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 Apr 2016 15:43:58 +0800
From:	Rongqing Li <rongqing.li@...driver.com>
To:	Yuki Machida <machida.yuki@...fujitsu.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: Section 4 No. 9,10 Failed was occurred by IPv6 Ready Logo
 Conformance Test



On 2016年04月01日 15:31, Yuki Machida wrote:
> Hi all,
> 
> I tested 4.6-rc1 by IPv6 Ready Logo Core Conformance Test.
> 4.6-rc1 has some FAILs in Section 4 (RFC 1981: Path MTU Discovery for IP version 6).
> I conformed that it was PASSed in 3.14.28 and it was FAILed in 4.1.17.
> I will find a patch between 3.14 and 4.1.
> 
> IPv6 Ready Logo
> https://www.ipv6ready.org/
> TAHI Project
> http://www.tahi.org/
> 
> I ran the IPv6 Ready Logo Core Conformance Test on Intel D510MO (Atom D510).
> It is using userland build with yocto project.
> 
> Test Environment
> Test Specification          : 4.0.6
> Tool Version                : REL_3_3_2
> Test Program Version        : V6LC_5_0_0
> Target Device               : Intel D510MO (Atom D510)
> 
> List of FAILs
> 
> Section 4: RFC 1981 - Path MTU Discovery for IPv6
> - Test v6LC.4.1.6: Receiving MTU Below IPv6 Minimum Link MTU
>    - No. 9 Part A: MTU equal to 56
>    - No.10 Part B: MTU equal to 1279
> 

apply this one

commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4
Author: Hangbin Liu <liuhangbin@...il.com>
Date:   Thu Jul 30 14:28:42 2015 +0800

    net/ipv6: add sysctl option accept_ra_min_hop_limit

    Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface")
    disabled accept hop limit from RA if it is smaller than the current hop
    limit for security stuff. But this behavior kind of break the RFC
definition.

    RFC 4861, 6.3.4.  Processing Received Router Advertisements
       A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time,
       and Retrans Timer) may contain a value denoting that it is
       unspecified.  In such cases, the parameter should be ignored and the
       host should continue using whatever value it is already using.

       If the received Cur Hop Limit value is non-zero, the host SHOULD set
       its CurHopLimit variable to the received value.

    So add sysctl option accept_ra_min_hop_limit to let user choose the
minimum
    hop limit value they can accept from RA. And set default to 1 to
meet RFC
    standards.

    Signed-off-by: Hangbin Liu <liuhangbin@...il.com>
    Acked-by: YOSHIFUJI Hideaki <hideaki.yoshifuji@...aclelinux.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>





and revert the below one, the TAHI should be updated

commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2
Author: Hagen Paul Pfeifer <hagen@...u.net>
Date: Thu Jan 15 22:34:25 2015 +0100

    ipv6: stop sending PTB packets for MTU < 1280

    Reduce the attack vector and stop generating IPv6 Fragment Header for
    paths with an MTU smaller than the minimum required IPv6 MTU
    size (1280 byte) - called atomic fragments.

    See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1]
    for more information and how this "feature" can be misused.

    [1]
https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00

    Signed-off-by: Fernando Gont <fgont@...networks.com>
    Signed-off-by: Hagen Paul Pfeifer <hagen@...u.net>
    Acked-by: Hannes Frederic Sowa <hannes@...essinduktion.org>
    Signed-off-by: David S. Miller <davem@...emloft.net>



-Roy




> Regards,
> Yuki Machida
> 

-- 
Best Reagrds,
Roy | RongQing Li