Hi Steve,

I have added a new section 4.3 and changed section 6.
The text below.
Does this text address your concerns?

Greetings and thanks for your reaction,

Peter


4.3.  Encryption rules

    An incoming message protected at layer-2 MUST be subsequently re-
    protected at layer-2 at all outgoing interfaces.  Incoming messages
    are integrity checked and optionally decrypted at the incoming
    interface at layer-2 using the keys and protection algorithm
    appropriate to the incoming interface's network and re-protected at
    the outgoing interface using the keys and protection algorithm
    appropriate to the outgoing interface's network.  It may be necessary
    to assess the relative levels of protection on the respective
    interfaces and apply policy rules, for example to avoid downgrading
    security where one network has a lower level of security than
    another.

    An incoming MPL4 messages which is not protected at layer-2 MUST NOT
    be re-protected at layer-2 at all outgoing interfaces.

7.  Security Considerations

    The security considerations of [I-D.ietf-roll-trickle-mcast] also
    apply to MPL4 routers.

    The sending of MPL4 messages by a malicious node can have unwanted
    consequences explained with the following example.  It is not unusual
    for a wired (e.g. ethernet) link to be used between two floors or
    sections of an LLN, as radio propogation through re-inforced concrete
    is generally poor.  The MPL4 zone can thus envelop mutiple routers,
    meshes and links.  It is possible that a malicious node connects to a
    wired link, on which no MPL enabled nodes are foreseen.  In this
    example configuration, the malicious node can send MPL4 messages to
    the MPL4 router interfaces.  When nothing is done, the MPL4 routers
    will consequently distribute MPL4 messages from one mesh over the
    wired link to the next mesh, although the wired link was not expected
    to transport MPL4 messages.

    To understand the consequences of this unwanted behaviour, the
    following cases should be distinguished:

    o  The source mesh uses layer-2 encryption.

    o  The MPL4 router can be managed.

    The four possible combinations are discussed below:

    Layer-2 unsecured, Router unmanaged:  In this case MPL4 messages are
       freely distributed over meshes and links which are interconnected
       by MPL4 routers within a zone.  The MPL enabled (malicious) nodes
       can read all MPL4 messages and distribute MPL4 messages over a
       network limited by a zone.  This situation can be acceptable for
       an isolated network, within a clearly defined space, where the
       connection of nodes can be tightly controlled.  A completely wired
       LLN -- such as is seen in BACnet -- is an example of an
       unencrypted LLN which would be considered physically secure.

    Layer-2 secured, Router unmanaged:  In this case MPL4 messages are
       freely distributed over meshes and links, which are interconnected
       by MPL4 routers within a zone.  Following the rules of
       Section 4.3, the MPL4 enabled (malicious) nodes can not read the
       MPL4 messages and MPL4 messages sent by the malicious node are not
       accepted by other nodes.  This situation is acceptable for a home
       network or managed network extending over precisely one zone,
       occupying a clearly defined physical space, where ease of
       installation is important.  In such a network, the presence of the
       malicious node is not different from any other malicious node,
       which tries to send messages over layer-2 protected links.
       Because the network occupies exactly one zone, the MPL4 message
       distribution cannot be extended outside the network.

    Layer-2 unsecured, Router managed:  In this case the distribution of
       MPL4 messages over MPL4 router interfaces can be limited to those
       interfaces, which a manager enabled for MPL and a set of multicast
       addresses.  The malicious node cannot extend the distribution of
       MPL4 messages over unwanted interfaces.  It is important that the
       handling of the interfaces by the manager is protected.  However,
       MPL4 messages sent over the mesh can be interpreted by malicious
       nodes and malicious messages can be injected into the set of
       meshes and links which are connected by the MPL4 routers for which
       the manager enabled the interfaces.  This situation can be
       practical for interconnected links and meshes, which are connected
       to a LAN over a limited period, for example during installation of
       the interconnected meshes and links.

    Layer-2 secured, Router managed:  In this case the distribution of
       MPL4 messages over MPL4 router interfaces can be limited to those
       interfaces, which a manager enabled for MPL and a set of multicast
       addresses.  Following the rules of Section 4.3, the malicious node
       cannot extend the distribution of MPL4 messages over unwanted
       interfaces and MPL4 messages sent by the malicious node are not
       accepted by other nodes.  It is important that the handling of the
       interfaces by the manager is protected.  The MPL enabled
       (malicious) nodes can not read the MPL4 messages and MPL4 messages
       sent by the malicious node are not accepted by other nodes.
       Dependent on the number of managed interfaces, the network can
       progressively pass from auto-configured to fully administratively
       controlled.


Steve.Hanna@infineon.com schreef op 2015-01-14 23:08:
> Rob,
> 
> I have removed areas where we agree below and added new comments
> marked with <steve2>.
> 
> Thanks,
> 
> Steve
> 
>>> After reading the document several times, I have concluded that
> 
>>> section 3.2 contains the most important part of the document: an
> 
>>> algorithm for automatically defining the boundaries of the
> admin-local
> 
>>> multicast scope using MPL. This section basically says that a
> border
> 
>>> router should periodically send an MPL message on all interfaces to
> 
>>> the ALL_MPL_FORWARDERS multicast address with admin-local scope. It
> 
>>> should also listen for such messages on all interfaces. If it
> receives
> 
>>> such a message, that interface should be marked as part of the
> 
>>> admin-local scope.
> 
>>> 
> 
>>> This algorithm seems problematic from a security standpoint.
> Because
> 
>>> any device on a network can send an MPL message to the
> 
>>> ALL_MPL_FORWARDERS multicast address with admin-local scope, the
> 
>>> boundaries of the admin-local multicast scope can be expanded by
> 
>>> attackers fairly easily.
> 
> <rcc>I guess it depends what you mean by "fairly easily". An attacker
> in
> 
> this case would have interfaces on more than one network and would
> have
> 
> to be authenticated on all networks in question. The attack scenario
> may
> 
> be just to attach to one network and then forward into other
> network(s)
> 
> which would not originally be considered part of the admin-local scope
> 
> 
> (which is I think what you are saying below) but it still has to
> 
> authenticate to the network being attacked and obtain the relevant key
> 
> 
> before its interface on that network can validly receive a MPL4
> 
> message.</rcc>
> 
> <steve2>I don't see why the attacker would need to have interfaces on
> 
> more than one network. See the ASCII art diagram below:
> 
> H1 - R - H2
> 
> Border router R has two network interfaces. H1 and H2 are hosts
> 
> connected to these interfaces. If both H1 and H2 send MPL4 messages
> 
> and R has MPL4 enabled on those interfaces, R will put both networks
> 
> into the same admin-local multicast scope. Am I wrong?
> 
> </steve2>
> 
>>> Such manipulation may permit nodes that
> 
>>> should be outside a particular administrative domain to join that
> 
>>> domain and participate in receiving and sending multicast traffic
> 
>>> within that domain. The implications of such an attack are not
> clear
> 
>>> to me because I am not familiar with the protocols and devices that
> 
>>> use admin-local multicast scope. However, it seems likely that
> 
>>> expanding the admin-local multicast scope will permit external
> 
>>> attackers to more easily monitor multicast traffic that should be
> 
>>> private and to inject multicast messages into a relatively trusted
> 
>>> domain.
> 
> <rcc>Again, it has to have been authenticated to one or more networks
> 
> and obtained the relevant key before it can do this.</rcc>
> 
>> <peter>
> 
>> In the discussion with Joel, we came to the conclusion that we were
> not
> 
>> very clear with respect to the administrative zone specification.
> 
>> We suggested to limit the mpl admin-local scope within one zone.
> 
>> The text will be extended to include this extra limit on the
> boundary of
> 
>> admin-local-scope.
> 
>> The extent of the scope does not specify anything about the contents
> of
> 
>> the MPL messages.
> 
>> It is expected that MPL messages are encrypted depending on the
> wanted
> 
>> security level.
> 
>> Monitoring by an attacker limits itself to counting messages, which
> is
> 
>> already possible on wireless links any way.
> 
>> To inject messages, the attacker should know the keys necessary to
> 
>> encrypt.
> 
>> When messages are not encrypted they are already readable on the
> 
>> wireless links, and the monitoring by extending the mpl-admin-local
> 
>> scope does not increase the vulnerability to snooping the messages.
> 
>> </peter>
> 
>> <steve>
> 
>> Please send me a copy of your new text limiting the admin-local
> scope
> 
>> to one zone. I don't see how this will help but maybe the new text
> will
> 
>> make it clear.
> 
>> 
> 
>> You just stated that "It is expected that MPL messages are
> encrypted".
> 
>> However, this is never stated in
> draft-ietf-roll-trickle-mcast-11.txt or in
> 
>> draft-ietf-roll-admin-local-policy-02.txt. In fact, there's no
> mention of
> 
>> encryption in those documents at all. If the security of your design
> 
>> depends on this encryption, you'd better talk about it somewhere!
> 
>> 
> 
>> Now I'd like to investigate the security provided by this
> encryption.
> 
>> Are you expecting that application-layer encryption will be used?
> 
>> I suppose not because that would require extensive description
> 
>> And you provided none. Probably you're thinking about link-layer
> 
>> encryption such as that provided by IEEE 802.11i. However, I don't
> 
>> think that such encryption will prevent the attacks that I
> described.
> 
>> 
> 
>> A border router frequently spans networks that are part of multiple
> 
>> administrative domains. Your current design (even with link
> encryption)
> 
>> means that any device connected to any of these networks can dictate
> 
>> the boundaries of the admin-local scope. Is it really desirable to
> trust
> 
>> all those devices to that extent? I think not.
> 
>> </steve>
> 
> <rcc>
> 
> The concept of scope, network boundary and security boundary are all
> 
> somewhat orthogonal. RFC7346 acknowledges this with additional text
> and
> 
> draft-ietf-roll-admin-local-policy explains how automatic
> configuration
> 
> for realm-local scope occurs in relation to a network identifier,
> which
> 
> then links network boundary and realm-local scope. However, there
> isn't
> 
> necessarily a one-to-one correspondence between security boundary and
> 
> network boundary even though it often happens in practice, e.g. a WPA2
> 
> 
> key for an 802.11 WLAN or network key for ZigBee IP WPAN, for example.
> 
> 
> Assuming this link-layer encryption, I don't think the attacks can
> take
> 
> place as an attacker would have to authenticate itself to the network
> 
> being attacked first or else it would not be able to validly received
> 
> the MPL4 message.
> 
> It is true that a border router configured with multiple MPL-enabled
> 
> interfaces does indeed by implication expand the admin-local scope,
> 
> however it is not obliged to have all its interfaces MPL-enabled; this
> 
> 
> is part of configuration as well, potentially controllable by some
> 
> superordinate entity.
> 
> Perhaps we need some extra text to explain this.
> 
> </rcc>
> 
> <steve2>
> 
> Certainly, if extending the admin-local scope has no security
> 
> implications, there's no security problem here. However, that
> 
> is probably not a universal understanding. You should explain
> 
> this issue in the Security Considerations section and describe
> 
> the circumstances when it is a problem and when it is not.
> 
> This will equip the reader to decide what to do. Just because
> 
> a host has the keys needed to join one network does not
> 
> mean that they should be permitted to change the admin-local
> 
> scope boundaries between that network and all other networks
> 
> joined via border routers.
> 
> </steve2>