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

Rene Struik <rstruik.ext@gmail.com> Fri, 30 May 2014 14:30 UTC

Message-ID: <538895DA.70806@gmail.com>
Date: Fri, 30 May 2014 10:29:46 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: robert.cragie@gridmerge.com, "Kumar, Sandeep" <sandeep.kumar@philips.com>, "dtls-iot@ietf.org" <dtls-iot@ietf.org>
References: <5384FB1C.60109@gmail.com> <5384FBB0.3040900@gmail.com> <BE6D13F6A4554947952B39008B0DC0153E79AB4A@DBXPRD9003MB059.MGDPHG.emi.philips.com> <5385FC6C.8080102@gmail.com> <BE6D13F6A4554947952B39008B0DC0153E79AD5A@DBXPRD9003MB059.MGDPHG.emi.philips.com>, <53860BB5.8020908@gmail.com> <BE6D13F6A4554947952B39008B0DC0153E79AF4E@DBXPRD9003MB059.MGDPHG.emi.philips.com> <538639AF.4050900@gmail.com> <538770D9.2040103@gridmerge.com> <5387963C.3070304@gmail.com> <53885131.7080900@gridmerge.com> <538890C6.6080901@gmail.com> <53889442.7040404@gridmerge.com>
In-Reply-To: <53889442.7040404@gridmerge.com>
Content-Type: multipart/alternative; boundary="------------070803040106080005000506"
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/U4bJYL5PyvN1mhuRWZVf48U7iYA
Subject: Re: [Dtls-iot] question on draft-kumar-dice-dtls-relay-01
Precedence: list

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] question on draft-kumar-dice-dtls-rela… Rene Struik
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Kumar, Sandeep
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Rene Struik
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Kumar, Sandeep
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Rene Struik
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Kumar, Sandeep
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Rene Struik
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Robert Cragie
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Rene Struik
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Robert Cragie
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Rene Struik
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Robert Cragie
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Rene Struik
Re: [Dtls-iot] question on draft-kumar-dice-dtls-… Robert Cragie