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

From: Tom Yu <[email-masked]>
Date: Sun, 08 Jun 2014 12:30:49 -0400

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.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 09 Jun 2014 08:30:17 -0400

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

---

From: Tom Yu <[email-masked]>
Date: Tue, 10 Jun 2014 00:24:18 -0400

> or greater than the scope contained in the multicast packet.

I'm not sure I see where that behavior is defined in RFC 4007, but
perhaps I lack context or am misreading something.  What happens when a
router receives a packet destined for an address having scope=3, but the
router doesn't have an explicitly-configured zone boundary for that
scope and also doesn't understand realm-local scope?  Would it drop the
packet (no routing information for the unconfigured zone of scope=3) or
restrict it to the largest zone of lower scope (protect inter-zone
integrity)?

Wouldn't forwarding that packet within a larger zone and scope cause the
packet to possibly leave its intended zone, where its destination
address might have a meaning unintended by the sender?

---

From: Brian Haberman <[email-masked]>
Date: Tue, 10 Jun 2014 08:20:04 -0400

Hi Tom,

> restrict it to the largest zone of lower scope (protect inter-zone

I think the context needed is in the second list in section 5 of 4007.
If a router does not have a boundary instantiated for scope=3 *or
larger*, the packet would be forwarded if forwarding state exists for
the multicast address.  If no forwarding state exists for that address
or a boundary exists for scope>=3, the packet is dropped.

> address might have a meaning unintended by the sender?

There are two rules in 4007 that cover this...

   o  Zones of the same scope cannot overlap; i.e., they can have no
      links or interfaces in common.

   o  A zone of a given scope (less than global) falls completely within
      zones of larger scope.  That is, a smaller scope zone cannot
      include more topology than would any larger scope zone with which
      it shares any links or interfaces.

Regards,
Brian