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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 09 July 2015 09:23 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8D11A8A3A; Thu, 9 Jul 2015 02:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTse0s7fA2dq; Thu, 9 Jul 2015 02:23:36 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938781A89F0; Thu, 9 Jul 2015 02:23:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 527A5BE54; Thu, 9 Jul 2015 10:23:35 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436433815; bh=8fF3FhsRmoKqpbnmQFNl7E6FnqXvOmXl1QB4UqCK4ko=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=Z9ON8wQ1QJq7xAtIuYaqjR5pLHnsGI1pv+DGUHD/7ZGPEl72Od42/TCuTzUaNIxTP VLMlMCVFjt+ESTkxfwZHuhxVfYiZlMqGCkUF1sbrZCsDMNUHtO0gR7hsX4o1klgNr4 52DnP4uHIlnC11T8zM6iaF6IYp3toQ3CY88gHuxU=
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3rcnoFqBz4Z; Thu, 9 Jul 2015 10:23:35 +0100 (IST)
Received: from [134.226.63.24] (cswireless63-24.scss.tcd.ie [134.226.63.24]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 17E14BE50; Thu, 9 Jul 2015 10:23:35 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436433815; bh=8fF3FhsRmoKqpbnmQFNl7E6FnqXvOmXl1QB4UqCK4ko=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=Z9ON8wQ1QJq7xAtIuYaqjR5pLHnsGI1pv+DGUHD/7ZGPEl72Od42/TCuTzUaNIxTP VLMlMCVFjt+ESTkxfwZHuhxVfYiZlMqGCkUF1sbrZCsDMNUHtO0gR7hsX4o1klgNr4 52DnP4uHIlnC11T8zM6iaF6IYp3toQ3CY88gHuxU=
Message-ID: <559E3D96.5050906@cs.tcd.ie>
Date: Thu, 09 Jul 2015 10:23:34 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Yusuke DOI <yusuke.doi@toshiba.co.jp>, The IESG <iesg@ietf.org>
References: <20150708080446.7700.80046.idtracker@ietfa.amsl.com> <559D3EE0.4000904@toshiba.co.jp>
In-Reply-To: <559D3EE0.4000904@toshiba.co.jp>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/0VoCAvAWODXXk83q6O2QOYJJhkw>
Cc: roll-chairs@ietf.org, draft-ietf-roll-mpl-parameter-configuration@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, draft-ietf-roll-mpl-parameter-configuration.shepherd@ietf.org, draft-ietf-roll-mpl-parameter-configuration.ad@ietf.org
Subject: Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2015 09:23:38 -0000

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
> 
>