Augment security considerations

draft-nbourbaki-6man-classless-ipv6.xml

@@ -134,17 +134,17 @@ don't een need /64 for SLAAC, except for backward compatibility. (*)
 -->
         </section>
 
-  <section anchor="notes" title="Notes and Recommendations">
+  <section anchor="notes" title="Recommendations">
 
-    <t>For historical reasons, when a prefix is needed on a link,
+    <t>For backwards compatibility, when a prefix is needed on a link,
-    barring other considerations, a /64 is traditional <xref
+    barring other considerations, a /64 is RECOMENDED <xref
     target="RFC7136"/>.</t>
 
-    <t>The length of the prefix identifier in Stateless Address
+    <t>The length of the Interface Identifier in Stateless Address
-    AutoConfiguration, <xref target="RFC4862"/> is a parameter; its
+    AutoConfiguration <xref target="RFC4862"/> is a parameter; its
     length needs to be sufficient for effective randomization for
     privacy reasons.  For example, a /48 might be sufficient.  But
-    operationally we recommend, barring strong considerations to the
+    operationally we RECOMMEND, barring strong considerations to the
     contrary, using 64-bits for SLAAC in order not to discover bugs
     where 64-bits was hard-coded, and to favor portability of devices
     and operating systems.</t>
@@ -153,7 +153,9 @@ don't een need /64 for SLAAC, except for backward compatibility. (*)
     should not operate with different interface identfier lengths on
     different physical interfaces.  Thus a correct implementation of
     SLAAC must in fact allow for any length of prefix, with the value
-    being parameterised per interface.</t>
+    being parameterised per interface. For instance, the Interface Identifier length in the recommended 
+    (see <xref target="RFC8064"/>) algorithm for selecting stable 
+    interface identifiers <xref target="RFC7217"/> is a parameter, rather than a hardcoded value.</t>
     
     <t>NOTE: should we comment on the fact that at least Linux and
     Windows seem to assume that the default prefix is /64 in the
@@ -163,10 +165,16 @@ don't een need /64 for SLAAC, except for backward compatibility. (*)
 
   <section anchor="security" title="Security Considerations">
 
-    <t>This document has no known security impact, assuming that
+<t>Assumming that nodes employ unpredictable interface identifiers <xref target="RFC7721"/>, the subnet size may have an 
-    user devices use an unpredictable interface identifier 
+impact on some security and privacy properties of a network. Namely, the smaller the subnet size, the more feasible it 
-    <xref target="RFC7721"/> for privacy.</t>
+becomes to perform IPv6 address scans <xref target="RFC7707"/> <xref target="RFC7721"/>.
+However, that for some specific subnets (such as point to point links), this may be less of an issue.</t>
 
+<t>On the other hand, we assume that a number of IPv6 implementations fail to enforce limits on the size of some of the data 
+structures they employ for communicating with neighboring nodes, such as the Neighbor Cache. In such cases, the use of smaller
+subnets essentially enforces an operational limit on such data structures, thus helping mitigate some pathological behaviors 
+(such as Neighbor Cache Exhaustion attacks).</t>
+<!-- [fgont] Still need to add references here... e.g. to Joel's RFC -->
     </section>
 
   <section anchor="iana" title="IANA Considerations">
@@ -210,6 +218,7 @@ don't een need /64 for SLAAC, except for backward compatibility. (*)
     <?rfc include="reference.RFC.6164"?>
     <?rfc include="reference.RFC.3587"?>
     <?rfc include="reference.RFC.4632"?>
+    <?rfc include="reference.RFC.7707"?>
     <?rfc include="reference.RFC.7136"?>
     <?rfc include="reference.RFC.7721"?>
     <?rfc include="reference.I-D.hinden-6man-rfc2464bis"?>