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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > _______________________________________________ v6ops mailing list [email protected] https://www.ietf.org/mailman/listinfo/v6ops -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
