Hi Joel, I've been and am in the middle of starting a new job and moving inter-state over the last few weeks, so I haven't been able to spend as much time on this as I'd have liked to, as I'm quite interested in this issue being resolved. I haven't had a chance, and won't over the next few weeks to thoroughly read the draft, hopefully below is useful.
I have been working on my own proposal to address this issue by abandoning the state held during the NS/NA transaction, and relying on the traffic originating hosts to retransmit their NS/NA triggering traffic if the stateless NS/NA transaction fails. On Sun, 7 Aug 2011 10:57:45 -0700 Joel Jaeggli <joe...@bogus.com> wrote: > Greetings, > > This is followup from our discussion in both v6ops and 6man. We got a lot of > useful input, but I would like to ask the mailing list to see if we can > solidify this into a course of action. > > For reference: > > ftp://ftp.ietf.org/internet-drafts/draft-gashinsky-v6nd-enhance-00.txt > > http://tools.ietf.org/agenda/81/slides/6man-9.pdf > > > 1. Is this document (draft-gashinsky-v6nd-enhance) worthwhile? > Yes > 2. Is there critique of the two proposed 4861 changes? > > A. 7.3 NDP Protocol Gratuitous NA > > a. We believe the is the question is whether the technique > would > be useful under duress, wether it is potentially dangerous, > if the safeguards are adequate, etc. > > B. 7.4 ND cache priming and refresh > Haven't had the chance to thoroughly understand them yet. > 3. Should we separate the potential mitigations (section 6) and > implementation advice (section 7.1 and 7.2) into a separate document. Yes. > > A. Assumption (validated in v6ops at ietf81) is that v6ops would be > happy > to take the mitigation and implementation advice as an informational > document > > B. Assumption 2 a draft updating 4861 would be a standards track > document. > > C. Assumption 3, should harmonize with > draft-nordmark-6man-impatient-nud-00 > > 4. Is there anyone who thinks that an update to 4861 to address dos exposure > is unnecessary? > I think this issue is essential to address. The end-users of the Internet, and the services/applications they use, usually reside on LANs, and LANs are vulnerable to this attack. The /127 or similar techniques aren't applicable to LANs or point-to-point links such as SP residential subscriber PPP/PPPoE sessions. A general method to resolve this issue for all links, regardless of their role in the network or their type should be the goal. > A. Just publish the advice and be done with it? > > Comments on some or all of these questions would help the authors decide > where to go next. > > Thanks > Joel HTH, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
