[secdir] secdir review of draft-ietf-6man-multicast-scopes-05

[Tom Yu <[e-mail]>]

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Summary: ready with minor issues.

This document defines the previously reserved IPv6 multicast scop value
3 to mean "realm-local scope".  The intent appears to be that
specifications about how to use IPv6 on top of the underlying link layer
technology define the extent of realm-local scope.  A potential minor
security issue is whether a router that does not understand scop 3
addresses (as specified by this draft) and receives a packet with a scop
3 destination address will forward the packet more widely than it
should, or otherwise behave unexpectedly.  This could be a problem for
some resource-constrained deployment scenarios envisioned for this
specification.

The Security Considerations section of this draft states

   "This document has no security considerations beyond those in RFC
   4007 [RFC4007] and RFC 4291 [RFC4291]."

I think this document potentially increases the security consequences of
behavior that was previously unspecified by RFC 4007 and RFC 4291.  RFC
4291 specifies the behavior of a node that receives a packet with a
multicast destination address with scop values 0 or F, but not for scop
3.  Packets with scop 0 destination addresses must be dropped, and
packets with scope F addresses must be treated as if they had global
(scop E) multicast addresses.

I can find no such previous specification for behavior for scop 3
packets.  This raises the question of how existing implementations would
behave if they were to receive packets destined to an address of scop 3,
and whether this poses any security exposure.  A conservative
implementation might drop the packets, or treat them as if they had scop
2 (link-local).  The requirements on scope zone boundaries specified in
Section 5 of RFC 4007 appear to make this latter behavior safe.

On the other hand, Section 4 of this draft updates RFC 4007 to resolve
an ambiguity about whether scope 3 is automatically or administratively
configured.  Existing text in RFC 4007 implies that scop 3 zone
boundaries are administratively configured, while RFC 4291 implies that
scop 4 (admin-local) is the smallest scope whose boundaries are
administratively configured.  I don't know whether existing
implementation behavior creates any practical security impact from this
ambiguity.

Because one stated use for realm-local scope is for multicast traffic in
mesh networks, which seem likely to be resource constrained (in power,
bandwidth, latency, error rate, etc.), I think it would be useful to
analyze the resource exhaustion or denial of service potential of mixed
deployments, where some routers understand the newly specified behavior
for scop 3 addresses and some do not.  I'm willing to believe that the
consequences are negligible.  It would be helpful to have a summary of
known or predicted behaviors of existing implementations regarding scop
3 addresses, along with some analysis of how acceptable the security
consequences of these behaviors are.