Subject: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 08 Jul 2015 01:04:46 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-roll-mpl-parameter-configuration-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I don't get the update model - if all MPL forwarders have
to use the same parameters but they don't all do DHCPv6 at
the same time, then won't new parameter settings take a
while to propagate to most of the network? And won't that
cause a problem? Don't you need a "start using this set of
parameters in N seconds" field in the dhcp option to handle
that? This is not a DISCUSS as I think it relats to Barry's
so please try address this when addressing that.

- please do not pretend rfc 3315 is a solution for anything
unless you mean it and I don't think you do. 3315 is I think
the canonical example for mythical security:-(

---

From: Yusuke DOI <[email-masked]>
Date: Thu, 09 Jul 2015 00:16:48 +0900

Hi Stephen,

Thank you very much for the review.

I believe your question is beyond Barry's DISCUSS. Let me clarify it here.

In general, all MPL Forwarders should have identical parameters to make 
a better load balance. However, the parameter synchronization is 'better 
to have' and even if there are mismatched parameter set it does not 
break interoperability or operation. Some forwarders would do more 
retransmission than others if the parameter is not identical. I consider 
this is acceptable behavior for MPL. To ease the unbalanced 
retransmission, I added some text to limit parameter update ratio per 
information refresh time.

For join and leave on forwarders, some node may not be able to receive 
messages during transitive period (not all forwarders have joined). 
However, adding some delay on the configuration will not ease the case. 
It's up to application to send a multicast message after all nodes have 
acquired the newest configuration, or to send a message during 
constructing MPL domain if the message is good even for delivered to a 
fraction of nodes.

> the canonical example for mythical security:-(

To be honest, my situation is to go without DHCPv6 security and expects 
network-level security. We do strict node admission using RFC5191 and 
assumes no untrusted node in a network.

I'm wondering how would I describe security consideration beyond my 
situation in the document, without relying on 3315. I appreciate if you 
give me some suggestion on this topic.

Thanks,

Yusuke

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Jul 2015 10:23:34 +0100

Hiya,

> constructing MPL domain if the message is good even for delivered to a

Hmm. I think what you're saying is that having the same parameters
is very nice but not absolutely needed. If that's the case then you
probably want to modify the text you use to motivate this draft where
you say that it's really needed.

> give me some suggestion on this topic.

I'd say take out the reference to 3315 entirely and just point at
some other RFC's security considerations text that says that we don't
have any real security for DHCP that works and as a result this and
that bad things can happen. If there are specific new bad things
that can happen related to this particular option being sent without
any crypto-security (which is what'll happen) then please note those.

(Some folks are trying to work on DHCP security but it'll take time
and in the meantime DHCP is just insecure.)

Cheers,
S.