Re: [Dtls-iot] question on draft-kumar-dice-dtls-relay-01

You need to be able to discover other networks if you are thinking of 
starting your own to make sure you don't collide. In this respect, you 
are an unauthenticated node to the other network. All I was saying is 
that the lock down mechanism is very commonly used and is a simple but 
effective way of preventing the ingress of unauthenticated data traffic 
(legitimate or otherwise) into the network.

Robert

On 30/05/2014 3:29 PM, Rene Struik wrote:
> Well, if you only allow devices to discover networks but not to join 
> them, this sounds like "window shopping", without a network ever being 
> able to form or expand.
>
> You seem to suggest that you always want to lock down the network 
> (join permit flag glued to the off position), the scenario I did not 
> bring up in my original email.
>
> On 5/30/2014 10:22 AM, Robert Cragie wrote:
>> Hi Rene,
>>
>> Comments inline.
>>
>> Robert
>>
>> On 30/05/2014 3:08 PM, Rene Struik wrote:
>>> Hi Robert:
>>>
>>> Obviously, when the network is locked down and does not allow newly 
>>> joining devices (the scenario where the relay on/off switch is stuck 
>>> in the OFF position), my initial question on relaying of messages 
>>> received from newly joining devices does not play. This would also 
>>> be the less interesting scenario, though, since this would not allow 
>>> devices to discover and join the network by themselves.
>> <RCC>It would potentially allow devices to discover networks but not 
>> to join them</RCC>
>>>
>>> BTW - even with stateless relay, the state of a relaying station may 
>>> change (e.g., due to impact of sending a MAC frame on MAC state); it 
>>> just does not accumulate state related to the newbee device. When 
>>> one uses TSCH, other MAC state may need to be introduced that may 
>>> relate to the newbee node, e.g., to synchronize timeslots during 
>>> which the newbee device and the relaying station can communicate. 
>>> So, the notion of "stateless" may be somewhat a misnomer, at least 
>>> for sleepy networks. In all cases, as already said, each relay of 
>>> end-to-end traffic may trigger amplified network traffic, so comes 
>>> at a price (network latency, consumed energy, capacity use, 
>>> intra-device computational latency). It is here where denial of 
>>> service attacks on the network may come into play.
>> <RCC>Of course, but the point is not to introduce any additional 
>> state through the relay mechanism itself, i.e. the net state change 
>> before and after the relay operation only. Beyond that anything can 
>> happen. DoS is a tricky subject to explore and can happen at various 
>> layers , for example, swamping a channel with noise is quite an 
>> effective localised DoS attack (PHY layer) or continuously sending a 
>> beacon request (MAC layer). What you describe above falls outside of 
>> the scope of the relay description and is specific to a certain type 
>> of network.</RCC>
>>>
>>> So, I am still interested in getting more insight as to how the 
>>> relay on/off switch would work in practice (which was the question 
>>> in my original email of Tue [snippet copied below]). A description 
>>> of device join operations would help (say, with operational network 
>>> of 1000 nodes with diameter 20 hops, where one wishes to add a 
>>> newbee node A at neighbor B, where B is 10 hops away from network 
>>> manager T).
>> <RCC>This only makes sense when a) considering a specific type of 
>> network, as you have done above and b) widening the scope of the 
>> discussion beyond just the relaying. Is that what you are proposing? 
>> If so, there need to be some bounds or else it could end up being a 
>> very long security considerations section.</RCC>
>>>
>>> I hope this helps.
>>>
>>> Rene
>>>
>>> [excerpt of my email as of Tue May 27, 2014, 4:55pm EDT]
>>> >>>> I would be curious as to whether you could provide some more 
>>> insight
>>> >>>> as to what type of denial of service attack you counter and how the
>>> >>>> DTLS Relay "on/off switch" would work in practice
>>>
>> [snip] 
>
>
> -- 
> email:rstruik.ext@gmail.com  | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
>
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot

Re: [Dtls-iot] question on draft-kumar-dice-dtls-relay-01

Attachment: smime.p7s