Re: [homenet] Alissa Cooper's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

Markus Stenberg <markus.stenberg@iki.fi> Fri, 20 November 2015 16:23 UTC

Return-Path: <markus.stenberg@iki.fi>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA9A1B2C44; Fri, 20 Nov 2015 08:23:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
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 1H72NlU11nm0; Fri, 20 Nov 2015 08:23:12 -0800 (PST)
Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.231]) by ietfa.amsl.com (Postfix) with ESMTP id E194F1B2C3A; Fri, 20 Nov 2015 08:23:11 -0800 (PST)
Received: from poro.lan (80.220.86.47) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 5613C7B1013C58BF; Fri, 20 Nov 2015 18:21:27 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <20151118194259.6263.86399.idtracker@ietfa.amsl.com>
Date: Fri, 20 Nov 2015 18:23:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C0363B5-84CB-4651-BAD7-86AF3903EF23@iki.fi>
References: <20151118194259.6263.86399.idtracker@ietfa.amsl.com>
To: Alissa Cooper <alissa@cooperw.in>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/s60kwLuF49glqpDt_SOmxNO-0ac>
Cc: homenet-chairs@ietf.org, homenet@ietf.org, Mark Townsley <mark@townsley.net>, The IESG <iesg@ietf.org>, draft-ietf-homenet-hncp@ietf.org
Subject: Re: [homenet] Alissa Cooper's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2015 16:23:13 -0000

Thanks for the comments ;)

On 18.11.2015, at 21.42, Alissa Cooper <alissa@cooperw.in>; wrote:
> -- How does a node end up in the leaf or guest category? Is it only if a
> fixed category is configured? If so, who decides that that configuration
> should happen? I think this info belongs in the draft.

Steven added some text on this related to some other DISCUSS:

>Note that all fixed categories
>except internal and external cannot be auto-detected and can only
>be selected using manual configuration.

> -- Section 5.1 says:
> 
> "Guest category:  This declares an interface used by untrusted client
>      devices only.  In addition to the restrictions of the Leaf
>      category, HNCP routers MUST filter traffic from and to the
>      interface such that connected devices are unable to reach other
>      devices inside the HNCP network or query services advertised by
>      them unless explicitly allowed."
> 
> What is the mechanism for explicitly allowing selective access for guest
> nodes? Is this left for firewall policy configuration? I think this
> warrants some explanation.

I think this is implementation choice for now; doing it interoperably is not within scope of this document at least, although someone could provide some HNCP TLVs for distributed firewall configuration in the future. (I am not sure if such exist in the IETF wild currently.)

> -- In Sec 6.4, I'm unclear on whether the address selection process
> specified in the bulleted list would ever be used to obtain a IPv6
> address. If not, then this comment is not relevant. But if it might be
> used in some case where the node is using v6 but for some reason cannot
> use the mechanism specified in RFC7217, I think additional guidance is
> needed here about self-assignment, in line with the ongoing work on
> draft-ietf-6man-default-iids. Nodes might be tempted to embed a
> link-layer address in the IID as a means of ensuring that their
> self-assigned addresses do not collide with others, but they should be
> discouraged from doing so. So I think some text to the effect that nodes
> SHOULD assign themselves semantically opaque addresses even if they
> cannot use the RFC7217 mechanism and SHOULD NOT embed the underlying
> link-layer address in the IID is warranted here.

I think it is essentially just fallback that I would rather not elaborate on - few reasons:

- RFC7217 is the SHOULD; not doing SHOULD requires good idea on why not to anyway
- the self-assignment preferences are likely to evolve over time (note: ongoing work)
- we are mostly talking about routers (=few connections outside the home) not hosts => I am not that worried about the IID hiding

However, if you can come up with a concise futureproof text that addresses the concern, I do not mind incorporating it. I personally am not sure how to phrase that. 

Cheers,

-Markus