Thanks! On Aug 7, 2011, at 2:58 PM, Mark Smith wrote:
> 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 --------------------------------------------------------------------
