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

[Brian Haberman <[e-mail]>]

Hi Tom,
     Thanks for the review.

     I do think that the rules in RFC 4007 adequately cover the boundary
handling for realm-scoped multicast addresses.  The general rule defined
in 4007 is that a multicast packet is forwarded if there is forwarding
state and a scope boundary is configured on the router that is equal to
or greater than the scope contained in the multicast packet.

     Since scope=3 has not been explicitly defined in another RFC, the
handling is strictly driven by 4007.  This draft is creating a more
tightly controlled use of scope=3 since it allows for the automatic
creation of a scope boundary where before (i.e., RFC 4007) an
administrator had to manually create the scope boundary.

     I am not sure what we would add to this document, but that is my
$0.02 on the issue.  SEC ADs?

Regards,
Brian

On 6/8/14 12:30 PM, Tom Yu wrote:
> 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.
>