Subject: [homenet] Alia Atlas' No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

From: "Alia Atlas" <[email-masked]>
Date: Fri, 20 Nov 2015 09:09:38 -0800

Alia Atlas 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:
----------------------------------------------------------------------

I support Brian's Discuss.

1)  In Sec 1.1, it states "...in homenet environments where multiple IPv6

   source-prefixes can be present, routing based on source and
destination 
   address is necessary [RFC7368]."
  
   Looking at RFC7368, I don't see anything that matches the strength of
this
   assertion which says in Sec 3.2.4 merely  "Another avenue is to
introduce support
   throughout the homenet for routing that is based on the source as
   well as the destination address of each packet."

   While src-dest routing is certainly a solution - and an interesting
one - it doesn't
   seem at all appropriate for an HNCP spec to assert that it is
necessary.

2) For the DNCP profile,  draft-ietf-homenet-dncp-12 says  "Anything
received over multicast, except Node Endpoint TLV (Section 7.2.1) and
Network State TLV (Section 7.2.2)." and this draft says "HNCP nodes MUST
ignore all Node State TLVs received via multicast
 on a link which has DNCP security enabled in order to prevent spoofing
of node state changes."
Could you please align and clarify the desired behavior for HNCP?

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 23 Nov 2015 19:16:57 +0200

Heya,

thanks for the review :)

True. However, we were asked to describe the applicability, and I consider e.g. tunneling solution inferior so I would rather not propose that here. (And you either need tunneling or src-dst routing for this to work, and defining new tunneling scheme just for this to work is much harder than saying src-dst). Without one of them, the solution will break BCP-38 and not work.

What would be the other realistic option to change here? The whole applicability mess showed up somewhere in the review process, and I would rather not have it, but dropping it is not an option either.

> Could you please align and clarify the desired behavior for HNCP?

The part you are quoting from DNCP profile notes only what _can_ be defined to be ignored by profiles. HNCP as written is correct.

I welcome deltas which make it more correct, but you did not quote the preceding paragraph which says this in DNCP:

   o  When receiving TLVs, what sort of TLVs are ignored in addition -
      as specified in Section 4.4 - e.g., for security reasons.  While
      the security of the node data published within the Node State TLVs
      is already ensured by the base specification (if secure unicast
      transport is enabled, Node State TLVs are sent only via unicast as
      multicast ones are ignored on receipt), if a profile adds TLVs
      that are sent outside the node data, a profile should indicate
      whether or not those TLVs should be ignored if they are received
      via multicast or non-secured unicast.  A DNCP profile may define
      the following DNCP TLVs to be safely ignored:

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 23 Nov 2015 20:02:11 +0100

>> one - it doesn't seem at all appropriate for an HNCP spec to assert
>> that it is necessary.

> True. However, we were asked to describe the applicability, and
> I consider e.g. tunneling solution inferior so I would rather not
> propose that here.

I was under the impression that there was consensus that tunnelling is
a bad idea, and that source-specific routing is superior.  I may be
mis-reading Alia, but perhaps she means that some deployments might not
require the added complexity of source-specific routing, and might be able
to get away with ordinary next-hop routing.  (Alia, apologies if
I misunderstood.)

Recall that our main concern is to ensure that Homenet routers from
different vendors interoperate.  Source-specific routing, when done right,
interoperates with ordinary next-hop routing under the following
conditions: (1) all edge routers are source-specific, (2) there is
a connected backbone of source-specific routers, and (3) at least one of
the routers in the backbone announces a non-specific default route.  (1)
and (3) are easy enough, but (2) is problematic: it is a global condition,
one that can only be verified with global knowledge of the topology.

So I agree with Markus -- while it might be possible to get away with
a weaker requirement, it is way simpler to make source-specific routing
a MUST.  If there is market demand, we might want to write a different
document that describes a weaker set of requirements for interior-only
(non-gateway-capable) Homenet nodes.

(A more desirable alternative, of course, would be to split the
requirements in HNCP into HNCP requirements and Homenet requirements, but
I gather that there's consensus that it's somewhat late to embark on such
an ambitious project.  I rather agree with that assessment -- we need to
get Homenet out of the door quickly, lest people start deploying IPv6 NAT.)

-- Juliusz