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

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 18 Nov 2015 11:42:59 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-homenet-hncp-09: 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-homenet-hncp/

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

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

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

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

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 20 Nov 2015 18:23:08 +0200

Thanks for the comments ;)

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.

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

> 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