Subject: Announcing Hashed SLND and other changes to draft-smith-6man-mitigate-nd-cache-dos-slnd

From: Oliver <[email-masked]>
Date: Fri, 19 Oct 2012 18:25:17 +0200

Link for convenience: http://tools.ietf.org/html/draft-smith-6man-mitigate-nd-
cache-dos-slnd-04

The following is a (non-exhaustive) overview of the changes:

1) Described Hashed SLND

2) Replaced TUSP with TUD

3) Clarified required & optional behaviour.

4) Expanded scope for SLND

5) fixed up a few nits.

Comment and feedback most appreciated.

Kind Regards,
Oliver

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Oct 2012 14:06:32 -0700 (PDT)

Hi,

While I appreciate the enthusiasm for the idea of stateless neighbor
discovery, none of these changes (versions 02 through 04) have gone
through me. I also assume that it is up to me as to whether Oliver becomes
co-author or not, as versions 00 and 01 were my individual work.

I'd appreciate some advice from the Working Group chairs as to what to do
in this situation.

Oliver, I think your Hashed SLND idea is different enough that it should be in
a separate ID, which I think should reference rather than be derived from a
copy of my ID. I have two concerns about it - firstly, it would significantly
increase the processing load on the control plane, due to the calculations
of hashes, which may create another opportunity for an attacker to DoS the
control plane of the router by exhausting it's CPU resources. Secondly,
it would require a router to assign those addresses to it's interface for
at least as long as the NS/NA transaction can take place, otherwise the
incoming NA would be dropped, and as these hashed addresses are derived from
the destination address that triggered the NS/NA transaction, this could
also create a DoS opportunity, as temporarily assigning these addresses
to the router's interface would also require state that could be exploited.

Ultimately, I think a host registration protocol is necessary to properly
solve the problem, as it ensures off-link hosts can't create any unnecessary
state or processing on routers, allows full logging of hosts that attach
to the network (which stateful DHCPv6 won't do because it doesn't record
host static address assignments), and prevents on-link hosts from spoofing
source addresses that fall within the local subnets, something that BCP38
can't do. My proposal is about mitigating the DoS opportunity for existing
hosts while a registration protocol is developed and deployed. It needs
to be kept simple so that it is both quick and easy to deploy, and not
become so "featureful" such that the effort involved in developing and
deploying it is taking time away from the effort involved in developing
and deploying a registration protocol.

Thanks,
Mark.

>________________________________
> From: Oliver <[email-masked]>
>To: [email-masked] 
>Sent: Saturday, 20 October 2012 3:25 AM
>Subject: Announcing Hashed SLND and other changes to draft-smith-6man-mitigate-nd-cache-dos-slnd
> 
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>
>
>

---

From: Oliver <[email-masked]>
Date: Sun, 21 Oct 2012 16:33:34 +0200

> co-author or not, as versions 00 and 01 were my individual work.

Mark & relevant parties,

Thank you for the clarification.

I unreservedly apologise for this faux pas, I was not aware this was 
inappropriate for the IETF document development process.

I hope all can understand that I acted in good faith - once again I apologise 
for this error, I will re-review the IETF Tao and related RFCs.

Kind Regards,
Oliver