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

[Joel Jaeggli <[e-mail]>]

I forgot to include 6man

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 "join" 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
> 

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops