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

[Stephen Farrell <[e-mail]>]

Hiya,

On 08/07/15 16:16, Yusuke DOI wrote:
> Hi Stephen,
> 
> Thank you very much for the review.
> 
> On 2015-07-08 17:04, Stephen Farrell wrote:
>> ----------------------------------------------------------------------
>> 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.
> 
> 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.

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.

> 
>> - 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:-(
> 
> 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.

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.


> 
> Thanks,
> 
> Yusuke
> 
>