On 16.9.2015, at 18.39, 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..
> So, this may turn into more of an IESG-based discussion. Given the
> generalities introduced by this "abstract protocol specification", I
> think it will be useful for the IESG to work this out.
Ok, looking forward to what you guys tell us to do about it :)
>> ’simple to implement’ (or ’not complex to implement’) could be added
>> there to the delta part though.
> IMO, it wouldn’t hurt.
Added in [1] (and simplified the text bit, I think saying that there is no
delta transmission scheme makes it obvious that you have to send the whole
thing).
> I am not sure how that helps in this case. What you want, I think, is
> to explicitly state that profiles of DNCP could specify exchanges that
> carry sensitive information and confidentiality is needed. Section 4.2
> is focused more on the underlying transport protocol (TCP vs. UDP) and
> the nebulous "security" term. The driver here should be whether
> authentication, integrity protection, confidentiality, or authorization
> is needed. Perhaps that would make sense in Section 9.
As currently specified, there isn’t really half-way choice in the spec (e.g. no
confidentiality); if you go for ‘insecure’, you get none, and if not, you are
essentially forced to integrity protection+confidentiality and your choice of
authentication+authorization (section 8).
Everything within node data is already covered by default (adding explicit
statement to that effect in [1]) given adherence of the secure <> not-secure
specification (notably, reception ignores Node State TLVs received via
multicast), but it is true that if a DNCP profile specifies TLVs that are sent
outside node data a security policy must be stated for them as well.
>>>>>>> * 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.
> I think that the MUST clause I quoted above from 4.4 needs to be put in
> context with what is stated in section 9.
Hm, true. Updated in [1] (also changed the ‘eventually’ to the meaning I meant,
that is, non-zero probability but not neccessarily probability of 1).
However, if the TLV is not forbidden
by the DNCP profile, an implementation MUST reply to resends of the
TLV with a non-zero probability to avoid starvation which would
break the state synchronization.
>> 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).
> What happens if that simple implementation is running on 1,000 nodes,
> they receive a multicast request from a single neighbor, and they all
> respond immediately without randomizing the transmit time of their
> responses?
Depends on the link layer to some extent; in worst case, none get through, and
eventually network gradually splits. In about any other case (say, even 10% get
through), the network converges, just bit slower (Trickled resends -> not even
that slowly). In practise, barring naive hubs of 90s, I am not aware of such a
link layer in use that would behave _that_ badly. Ethernet switches avoid
mostly collisions these days, and wifi unicast is ‘reliable’. Therefore I
consider it a SHOULD; certainly, _for some link layer_, you may want it a MUST,
but in general, I think MUST increases implementation complexity more than it
brings to the table.
(I have yet to see a problem in real world due to this; then again, I do not
have 1000 nodes on a single flat link..)
That said, if this gets deployed on such a network, I will gladly publish an
errata saying MUST :-)
Cheers,
-Markus
[1]
https://github.com/fingon/ietf-drafts/commit/e3dde8c59785bc509252978f73bb6532b3c7cc73
- to appear in -10.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
