1. 05 9月, 2013 3 次提交
    • D
      net: ipv6: mld: get rid of MLDV2_MRC and simplify calculation · e3f5b170
      Daniel Borkmann 提交于
      Get rid of MLDV2_MRC and use our new macros for mantisse and
      exponent to calculate Maximum Response Delay out of the Maximum
      Response Code.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3f5b170
    • D
      net: ipv6: mld: clean up MLD_V1_SEEN macro · 6c567b78
      Daniel Borkmann 提交于
      Replace the macro with a function to make it more readable. GCC will
      eventually decide whether to inline this or not (also, that's not
      fast-path anyway).
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c567b78
    • D
      net: ipv6: mld: fix v1/v2 switchback timeout to rfc3810, 9.12. · 89225d1c
      Daniel Borkmann 提交于
      i) RFC3810, 9.2. Query Interval [QI] says:
      
         The Query Interval variable denotes the interval between General
         Queries sent by the Querier. Default value: 125 seconds. [...]
      
      ii) RFC3810, 9.3. Query Response Interval [QRI] says:
      
        The Maximum Response Delay used to calculate the Maximum Response
        Code inserted into the periodic General Queries. Default value:
        10000 (10 seconds) [...] The number of seconds represented by the
        [Query Response Interval] must be less than the [Query Interval].
      
      iii) RFC3810, 9.12. Older Version Querier Present Timeout [OVQPT] says:
      
        The Older Version Querier Present Timeout is the time-out for
        transitioning a host back to MLDv2 Host Compatibility Mode. When an
        MLDv1 query is received, MLDv2 hosts set their Older Version Querier
        Present Timer to [Older Version Querier Present Timeout].
      
        This value MUST be ([Robustness Variable] times (the [Query Interval]
        in the last Query received)) plus ([Query Response Interval]).
      
      Hence, on *default* the timeout results in:
      
        [RV] = 2, [QI] = 125sec, [QRI] = 10sec
        [OVQPT] = [RV] * [QI] + [QRI] = 260sec
      
      Having that said, we currently calculate [OVQPT] (here given as 'switchback'
      variable) as ...
      
        switchback = (idev->mc_qrv + 1) * max_delay
      
      RFC3810, 9.12. says "the [Query Interval] in the last Query received". In
      section "9.14. Configuring timers", it is said:
      
        This section is meant to provide advice to network administrators on
        how to tune these settings to their network. Ambitious router
        implementations might tune these settings dynamically based upon
        changing characteristics of the network. [...]
      
      iv) RFC38010, 9.14.2. Query Interval:
      
        The overall level of periodic MLD traffic is inversely proportional
        to the Query Interval. A longer Query Interval results in a lower
        overall level of MLD traffic. The value of the Query Interval MUST
        be equal to or greater than the Maximum Response Delay used to
        calculate the Maximum Response Code inserted in General Query
        messages.
      
      I assume that was why switchback is calculated as is (3 * max_delay), although
      this setting seems to be meant for routers only to configure their [QI]
      interval for non-default intervals. So usage here like this is clearly wrong.
      
      Concluding, the current behaviour in IPv6's multicast code is not conform
      to the RFC as switch back is calculated wrongly. That is, it has a too small
      value, so MLDv2 hosts switch back again to MLDv2 way too early, i.e. ~30secs
      instead of ~260secs on default.
      
      Hence, introduce necessary helper functions and fix this up properly as it
      should be.
      
      Introduced in 06da92283 ("[IPV6]: Add MLDv2 support."). Credits to Hannes
      Frederic Sowa who also had a hand in this as well. Also thanks to Hangbin Liu
      who did initial testing.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: David Stevens <dlstevens@us.ibm.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      89225d1c
  2. 04 9月, 2013 8 次提交
  3. 01 9月, 2013 10 次提交
  4. 31 8月, 2013 1 次提交
  5. 30 8月, 2013 1 次提交
  6. 28 8月, 2013 5 次提交
  7. 23 8月, 2013 1 次提交
  8. 21 8月, 2013 7 次提交
  9. 20 8月, 2013 2 次提交
    • H
      ipv6: drop packets with multiple fragmentation headers · f46078cf
      Hannes Frederic Sowa 提交于
      It is not allowed for an ipv6 packet to contain multiple fragmentation
      headers. So discard packets which were already reassembled by
      fragmentation logic and send back a parameter problem icmp.
      
      The updates for RFC 6980 will come in later, I have to do a bit more
      research here.
      
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f46078cf
    • H
      ipv6: remove max_addresses check from ipv6_create_tempaddr · 4b08a8f1
      Hannes Frederic Sowa 提交于
      Because of the max_addresses check attackers were able to disable privacy
      extensions on an interface by creating enough autoconfigured addresses:
      
      <http://seclists.org/oss-sec/2012/q4/292>
      
      But the check is not actually needed: max_addresses protects the
      kernel to install too many ipv6 addresses on an interface and guards
      addrconf_prefix_rcv to install further addresses as soon as this limit
      is reached. We only generate temporary addresses in direct response of
      a new address showing up. As soon as we filled up the maximum number of
      addresses of an interface, we stop installing more addresses and thus
      also stop generating more temp addresses.
      
      Even if the attacker tries to generate a lot of temporary addresses
      by announcing a prefix and removing it again (lifetime == 0) we won't
      install more temp addresses, because the temporary addresses do count
      to the maximum number of addresses, thus we would stop installing new
      autoconfigured addresses when the limit is reached.
      
      This patch fixes CVE-2013-0343 (but other layer-2 attacks are still
      possible).
      
      Thanks to Ding Tianhong to bring this topic up again.
      
      Cc: Ding Tianhong <dingtianhong@huawei.com>
      Cc: George Kargiotakis <kargig@void.gr>
      Cc: P J P <ppandit@redhat.com>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4b08a8f1
  10. 16 8月, 2013 1 次提交
  11. 15 8月, 2013 1 次提交
    • N
      ip6tnl: add x-netns support · 0bd87628
      Nicolas Dichtel 提交于
      This patch allows to switch the netns when packet is encapsulated or
      decapsulated. In other word, the encapsulated packet is received in a netns,
      where the lookup is done to find the tunnel. Once the tunnel is found, the
      packet is decapsulated and injecting into the corresponding interface which
      stands to another netns.
      
      When one of the two netns is removed, the tunnel is destroyed.
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0bd87628