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

[Markus Stenberg <[e-mail]>]

Heya,

thanks for the review :)

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

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.

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

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