Subject: Re: [v6ops] new draft: draft-gashinsky-v6nd-enhance-00

From: Joel Jaeggli <[email-masked]>
Date: Sun, 3 Jul 2011 16:18:28 -0700

On Jul 1, 2011, at 7:52 PM, Andrew Yourtchenko wrote:

> Joel,
> 
> FWIW, a couple of observations about the "6.3. Routing Mitigation" based on my experiments and various discussions, and a few miscellanea.
> 
> 6.2. Appropriate Subnet Sizing.
> 
> Maybe worth to note here that the folks would still benefit of allocating the /64, and then using smaller part of it, if they want to do so. So later if they need to have more hosts in that segment, they would only renumber that segment. (also to "optimize the allocation for conservation of braincells" which I remember someone mentioned some time)

fwiw that's essentially what I did in practice, e.g. I assign p-to-p links as /64s and user them with much shorter. load balancer virtual ip's are all assigned out of the same /64 but are actually used as /128s.  use of non-default subnet size on the other hand runs afoul of SLAAC so it has it's limitations.

> Also for consistency with 6.1, might be worth noting that this approach would inhibit the use of RFC4862 altogether ?
> 
> 6.3. Routing Mitigation.
> 
> - the necessity to enable routing will depend on whether the host implements Strong ES or Weak ES multihoming model as per rfc1122 terminology - I tested on 2.6.32-24-generic and reaching the global address configured on the "lo" interface from ethernet side did not require enabling the forwarding.
> 
> - one semi-related advantage of the routing approach is that it can and is used in operations to allow the routing-protocol based redundancy with anycast addresses for transactional services.
> 
> - the overhead on the host will of course depend on the type of the routing protocol. Also, since it is effectively host->router communication, one can take an advantage of that. The RIPng seemed like a good candidate to me in this regard (to be run only on the first hop router).
> The prototype code is 205 lines of vanilla C, of which 113 lines are the RT_NETLINK boilerplate to retrieve the current address(es) assigned to loopback interface, such that the host config files were the only dependency.
> 
> (IMHO this approach is effectively a 7.3, but at network layer at an expense of some addition to host. Arguably, http server code is also an addition, though :).
> 
> - one other side effect of this approach is that if it is used in the NBMA-type ethernet deployment (cf: the RA thread), then the absence of the on-link global prefix takes care of the inter-host communication - it will happen via the default gateway.
> 
> 
> 7.1, item 5: Recommendations for Implementors.
> 
> keeping the state here opens the hole from another end - if a router "remembers" the "past good" addresses, then a local attacker may easily exhaust the resources on the router by rapidly changing the source address and making a single ping, then moving on.

yeah I think what exposure a malicious local system might exploit is worth a thought expierment or two.

> 7.2. Queue Tuning.
> 
> How does this interact with the other aspect of the behavior that is dictated by RFC4861 ?
> 
> "While waiting for address resolution to complete, the sender MUST,
>  for each neighbor, retain a small queue of packets waiting for
>  address resolution to complete. "
> 
> Merely rate-limiting the requests from the dataplane would result in inability for an implementation to comply with this "MUST", I think.

yeah

> Also, to me this section seems to contradict the 6.4:  the 7.2 says it's applicable if there is a single queue, while 6.4 says it is useful only if there is more than one queue - while 7.2 reads as the suggestion to implement the knobs for doing 6.4... If I miss something more subtle here, might be useful to have it more explicit (and as well to expand on the relationship between the two chapters).
> 
> 7.3. NDP Protocol Gratuitous NA
> 
> "Hosts MAY be configured to send unsolicited Neighbor advertisement..." - is it something that exists now somewhere in the OS or would this require additional code as well ? The implementations I know of, used ad-hoc appendages to send these NAs. Ergo, I think it is similar to section 6.3 except it uses the different name for the protocol ?

So NDP, as it exists today assumes that a gratuitious NA message kicks of a NDP cycle. regarding whether implementations do something along these links I'm pretty sure that host implmentations for vrrp6 pretty much do that when transitioning the shared address between instaces.

> I wonder if there is a room for "neighbor registration" approach similar to the one in http://tools.ietf.org/html/draft-ietf-6lowpan-nd.
> 
> 9.
> 
> "... DOS exposure" is the ending of the sentence or there is something more ?
> 
> s/Explicitely/Explicitly/
> s/maintin/maintain/
> s/amerlorate/ameliorate/
> s/isse/issue/
> s/excissivly/excessively/
> s/lowing/lowering/
> s/investigationg/investigating/
> s/maintaice/maintenance/
> s/recieving/receiving/
> s/correpsonding/corresponding/

thanks

> cheers,
> andrew
> 
> On Thu, 30 Jun 2011, Joel Jaeggli wrote:
> 
>> I would direct the two working groups' attention if I may to a recently posted draft:
>> 
>> http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00
>> 
>> the potential DOS exposure that ipv6 neighbor discovery poses to routers is generally understood at this  point, the document covers usable work arounds, and includes some rough proposals for addressing what the authors views as shortcomings in the neighbor disocvery process.
>> 
>> some inspiration was drawn from:
>> 
>> http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-00
>> 
>> thanks
>> joel
>> 
>> A new version of I-D, draft-gashinsky-v6nd-enhance-00.txt has been successfully submitted by joel jaeggli and posted to the IETF repository.
>> 
>> Filename:	 draft-gashinsky-v6nd-enhance
>> Revision:	 00
>> Title:		 Operational Neighbor Discovery Problems and Enhancements.
>> Creation date:	 2011-06-29
>> WG ID:		 Individual Submission
>> Number of pages: 15
>> 
>> Abstract:
>> In IPv4, subnets are generally small, made just large enough to cover
>> the actual number of machines on the subnet.  In contrast, the
>> default IPv6 subnet size is a /64, a number so large it covers
>> trillions of addresses, the overwhelming number of which will be
>> unassigned.  Consequently, simplistic implementations of Neighbor
>> Discovery can be vulnerable to denial of service attacks whereby they
>> attempt to perform address resolution for large numbers of unassigned
>> addresses.  Such denial of attacks can be launched intentionally (by
>> an attacker), or result from legitimate operational tools that scan
>> networks for inventory and other purposes.  As a result of these
>> vulnerabilities, new devices may not be able to &quot;join&quot; a network, it
>> may be impossible to establish new IPv6 flows, and existing ipv6
>> transported flows may be interrupted.
>> 
>> This document describes the problem in detail and suggests possible
>> implementation improvements as well as operational mitigation
>> techniques that can in some cases to protect against such attacks.
>> It also discusses possible modifications to the traditional [RFC4861]
>> neighbor discovery protocol itself.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
>

---

From: Ray Hunter <[email-masked]>
Date: Tue, 05 Jul 2011 11:04:16 +0200

Thanks for releasing this draft.

Following all IMVHO from an operational perspective regarding 
differences of IPv4 and IPv6 network ingress and egress filtering.

I personally believe that the problem description for ND also needs to 
address the fact that there's a large number of potential source 
addresses, as well as potential destination addresses: it's a 
symmetrical problem.

p4 section2. "When such probes are directed via a router" talks about 
scans causing problems for a router.

Is there also a local on-wire attack possible on important server hosts? 
In IPv4, those hosts could also implement tight ingress and egress 
filters on a local machine-specific firewall. In IPv6, if an attacker 
compromises one host on the wire, they can use that as a springboard to 
attack other hosts. By sending many spoofed source addresses from a raw 
socket, the attacker can exhaust or abuse resources associated with ND 
or other server processes on the target server machine. OK it's fairly 
similar to IPv4 ARP flooding, but the attack surface is that much 
bigger, again because the ingress filters on the target can't be as 
tight on an IPv6 /64 as say an IPv4/24: that's 12 orders of magnitude 
difference. PVLAN and disallowing host to host communication might still 
be an effective mitigation.

Is there not also a related case (not directly relevant for ND) whereby 
an off-wire attacker now has access to far more source addresses than 
before?

SYN flooding prevention and other attack mitigation techniques have led 
to the implementation of automatic rate-limit filters in firewalls.

In the past, a DDOS attack on the Internet required access to a large 
number of machines, because IPv4 source addresses were in short supply 
and each attack machine was effectively limited to a single IPv4/32 
public IP source address. Now an attacker can easily obtain one or more 
temporary IPv6/48 today (via any tunnel broker provider and a spoofed 
email address). Even if the defender filters in firewalls at the IPv6/64 
level instead of the IPv4/32 level, that still means that each attacking 
host can send 2^16 different unique IPv6/64 prefixes to the target for 
each IPv6/48 prefix it has locally. A change in ratio of 2^16:1 compared 
to today.

Effectively, this could reduce the size of the botnet required to 
generate a significant attack by 2^16 or nearly 5 orders of magnitude 
unless defence mechanisms are radically improved compared to just 
filtering and rate limiting on IPv4/32 and IPv6/64.

The attacker could also harvest any replies by setting the local kernel 
interface into promiscuous mode, whilst also spoofing a large number of 
source machines (unlike today, where net edge ingress and egress filters 
would typically limit that to 1 IPv4/32 on the Internet or at most an 
IPv4 subnet worth of machines in a corporate net = on average say ±256 
potentially different source addresses).  Again a change in ratio of 
approx 2^16:1.

Whilst not specifically ND related, it could also change the odds in 
favor of the attacker.

I'd like to see whether it would be benefical for automated filters and 
other ingress and egress mitigation filter techniques to not only just 
filter or rate limit at the IPv6/64 and IPv4/32 level, but also track in 
parallel the SYN packet/attack rates at IPv6/128 IPv6/48 IPv6/40 IPv6/32 
IPv6/16 prefix level simultaneously, with each successively wider filter 
in turn protecting the narrower filters from resource depletion. [If you 
only track and filter at the IPv6/64 level, the firewall itself could 
become a target of a DOS attack for someone with access to multiple /48's]

I completely agree such filtering is onerous, but what other tools do we 
have? Especially for a zero day exploit.

I guess the ultimate operational mitigation for ND at the network edge 
is to configure each critical edge server as a point to point link to a 
dedicated L3 router port with simple static routing. [not mentioned in 
your paper, but a variation on 6.3 Routing Mitigation.]  High 
availability may of course be an issue that forces you to use shorter 
prefixes or dynamic routing.

regards,
RayH