On 9/15/15 2:45 PM, Markus Stenberg wrote: > On 15.9.2015, at 20.24, Brian Haberman <[email protected]> > wrote: >> On 9/15/15 12:52 PM, Steven Barth wrote: >>> Hello Brian, thank you for your feedback. >>> >>>> ---------------------------------------------------------------------- >>>> >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> I have no objections to the publication of this document, but I do have a >>>> couple of points that I want to discuss... >>>> >>>> * The spec says that all TLVs are transmitted every time any >>>> value in the TLV set changes. Section 1 says that a delta >>>> synchronization scheme is not defined. What is the >>>> justification for not using a delta synchronization approach? >>>> The ordering of the TLVs needed to compute the hash can be done >>>> at the receiver and a delta approach would minimize bandwidth >>>> consumption. I think it would be useful to provide some >>>> justification in the spec for the design decision made to not >>>> use a delta synchronization approach. >>> >>> Delta synchronization was mainly omitted due to our intended goal >>> of focusing on optimizing for simplicity and only infrequent and >>> potentially larger (in relation to the whole dataset) state >>> changes as noted in 1.1. Applicability. It is therefore not in >>> the base draft, however it should not be too difficult for a >>> DNCP-based protocol that is in need of such a feature (e.g. due >>> to it being "on the edge" of DNCPs applicability) to add it as an >>> extension. >> My point above comes from this in section 1.1: >> >> Another consideration is the size of the published TLV set by a >> node compared to the size of deltas in the TLV set. If the TLV >> set published by a node is very large, and has frequent small >> changes, DNCP as currently specified may be unsuitable since it >> does not define any delta synchronization scheme but always >> transmits the complete updated TLV set verbatim. >> >> The tradeoffs here really focus on the whether those "frequent >> small changes" are isolated to 1 or 2 TLVs or are spread out across >> all the TLVs. I don't think there is any concrete statement that >> can be made in this document as to where the inflection point is in >> this decision. >> >> It seems to me that the justification for not doing delta updates >> is really just simplicity in implementation. That is a perfectly >> fine reason in my opinion. I think the hand waving around the >> above and the computation of A_NC_I really don’t provide useful >> justification. > > A_NC_I calculation does not depend on how you synchronize things > (full state dump <> delta). It is mostly about value <> cost of > having Trickle, as opposed to fixed timers. > > What would you propose then?
My proposal is based on the observation that the design decisions made appear to be really grounded in simplicity of implementation. And, to me, that is perfectly fine. I think the discussion of justification in the Applicability section should simply focus on that simplicity and not theoretical arguments about relationships between various variables. If this were a full-blown protocol specification (e.g., an actual profile spec), I would expect more focused justification. > >>>> * Section 4.4 says that all responses are sent unicast, even >>>> for requests received via multicast over a multi-access medium. >>>> Was consideration given to use multicast responses and >>>> supporting message suppression on other nodes? Or, was the >>>> design decision made to ensure that all nodes responded with >>>> their TLV set to the requester? Either approach may be >>>> reasonable, but there is no justification given. >>> There are multiple factors involved here. One important issue is >>> that securing these multicast transactions is difficult and I >>> don't even know if there is a standardized and deployed way to do >>> this e.g. using (D)TLS that we use for unicast. This is slightly >>> touched in 4.2. Data Transport and 10. Security Considerations. >> Depends on what you mean by securing them. Is there really a need >> to provide confidentiality? It seems like the necessary security >> functions are integrity and authentication. Given that, multicast >> responses are quite feasible. But, that really doesn’t address my >> question... > > Yes, on insecure links, c.f. HNCP document, we transmit PSK for other > protocols there. > > (And yes, we could also specify this in the HNCP’s profile; however, > the more abstract we make the DNCP itself, the less reusable it is if > all operating constraints are actually specified in a profile.) > >> There are useful benefits to multicast responses, one primary one >> being that everyone who receives the multicast response can update >> their state for the sending node. On the flip side, a unicast >> response forces all nodes to respond and provide their TLV sets. >> >> The problem is that these benefits seem better suited for the >> profile documents that use DNCP. I don't see the need to pick one >> response method over another in this base specification. > > I guess this boils down to how many options we want to leave open; > certainly, this is (yet another) thing that could be left to > profiles. Actually, your earlier response about DNCP carrying PSK for other protocols is a fine justification for needing encryption and there not being a viable multicast security mechanism to use in such cases. Perhaps all you need is a statement in 4.4 that says that DNCP instantiations may carry sensitive information for other protocols and unicast-based security mechanisms are necessary to ensure confidentiality. > >>>> * When responding to a multicast request over a multi-access >>>> medium, why is the randomization of the transmit time only a >>>> SHOULD? I would think that needs to be a MUST. >>> I think this more or less depends on the type of link and its >>> characteristics and the current state, so I'm not sure if a MUST >>> is necessary in all cases. >> Multicast-based implosion is a problem. If implementations ignore >> the SHOULD, you run a very real risk of overloading the request >> sender with unicast responses. If the WG is not willing to make >> this a MUST, the spec should clearly spell out the potential of >> amplification attacks using this protocol. > > I am not sure what you mean by this, as I cannot really see it; in > _some applications_ on _some links_ perhaps, with bad implementations > _without rate limiting_ (that is stated that is acceptable for about > anything in the message processing flow). > > As specified, the _only_ multicast TLV that MUST be responded is the > Network State TLV, and those replies MUST be rate limited already. I don't think that is true based on this statement in the draft: However, an implementation MUST eventually reply to similar repeated requests, as otherwise state synchronization breaks. Does that not apply to any TLV sent via multicast? > > How many more MUSTs should we stick here? Whether you rate limit it > to one response per time interval (current), or mandatory delay (what > I guess you propose), I do not think it makes much of a difference. > > That said, if we go with your proposal to allow for multicast > response with multiple types to be the MUST path, then this needs to > be reconsidered. The original design _was_ to minimize the amount of > multicast, and for that the SHOULD delay (+ MUST rate limit replies > in general) seems sufficient to me. I think we are talking about different things. I am wondering why the randomization of response transmission *to multicasted requests* is only a SHOULD and not a MUST. Amplification attacks can be (and have been) launched by sending multicast messages that result in a large number of unicast responses hitting the source IP address of the request. Let me ask my question a different way... Can you provide an example of where nodes that receive a DNCP request via multicast should not randomize the transmit time of their responses? Regards, Brian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
