On 15.9.2015, at 22.10, Brian Haberman <[email protected]> wrote: >> >> 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.
Hmm. T. Clausen review told us that we should essentially describe what this is good for; that calculation explains where it is applicable. We got push-back from some other reviewers where we used less exact terms like ’small to medium sized networks of nodes with low amount of change’ in some iteration of the document (’small’? ‘medium’? ‘low’?). We even got asked for explicitly writing out intervals to the introduction of an abstract protocol earlier.. ’simple to implement’ (or ’not complex to implement’) could be added there to the delta part though. >>>>> * 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. Section 4.2? As multicast is used only to identify potential new DNCP nodes and to send status messages which merely notify that a unicast exchange should be triggered, the multicast transport does not have to be secured. If unicast security is desired and one of the built- in security methods is to be used, support for some TLS-derived transport scheme - such as TLS [RFC5246] on top of TCP or DTLS [RFC6347] on top of UDP - is also required. >>>>> * 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? Depends on profile (see section 9). I wonder how this should be rephrased to make it more clear; as what DNCP spec _says_ essentially that only mandatory to send/receive multicast TLV is the Network State TLV (+ associated Node Endpoint TLV), and everything else comes from the unicast reply sequences stemming from there. Receiving other TLVs via multicast is allowed but they are not explicitly generated by the default processing flow, and the section 9 describes which multicast TLVs can be explicitly ignored in a profile without breaking DNCP synchronization mechanism, and it turns out to be all of them except for the two noted above. They were left as options to allow e.g. sending multicast Node State TLVs _with data_ in profiles where confidentiality of the data does not matter. >> 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? Simple implementation[1] with a super paranoid profile (handles only those two above multicast TLVs) with the mandatory MUST ratelimit Request Network State TLVs. It does not really matter if it sends the one reply per link per Trickle interval either immediately or after delay for most part (barring some crippled link layers). Cheers, -Markus [1] ~500 LoC of Python for ‘full’ minimal DNCP implementation with HNCP-ish transport profile (which does not have any frilly bits) that I use for my home automation :) _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
