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

From: Rene Struik <[email-masked]>
Date: Tue, 27 May 2014 16:55:12 -0400

Dear Sandeep, Oscar, Sye Loong:

I read draft-kumar-dice-dtls-relay-01 a few days ago. In the security
considerations section of that draft, you allude to potential denial of
services attacks in the context where a one-hop neighbor of a joining
node facilitates messaging between that joining node and the network
manager potentially many hops away, where the joining node and the
network manager act as DTLS Client and DTLS Server, respectively, and
where the one-hop neighbor acts as DTLS Relay. You also suggest some
measures to thwart/limit denial of service attack risk.

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. How would one detect a
potential DoS attack and turn on the "DTLS Relay on/off" knobs to
counter an influx of bogus join protocol messages that could be
amplified if this would travel to the network manager (in a scenario
where both are many hops away from each other)? Since with DTLS, client
authentication only happens in the third protocol flow, it seems that by
necessity one has to allow three subsequent message flows (key
establishment messages from client to server and back, key confirmation
message from client to server), without the DTLS Relay element having a
mechanism (except for throttling) to cryptographically arbitrage these
flows.

When does the newbee device get configuration info and, e.g., a routable
address assigned?

If you could expand on this scenario, that would be great.

Best regards, Rene

[excerpt from draft-kumar-dice-dtls-relay-01]
5. Security Considerations
Additional security considerations need to be taken into account about
forwarding of messages from devices through a network to which it has
not yet been admitted. This can lead to denial-of-service attacks or
misuse of network resources without proper authentication. One way to
overcome any large scale misuse of the network is to have a management
message from the Controller that initiates already authenticated devices
in the network to enter into a DTLS Relay mode. The devices can stay
such a Relay mode for a fixed period of time or until the Controller
sends a new management message blocking the DTLS Relay mode in all
devices in the network. This is often possible since the administrator
of the network can be aware when new devices join the network either
because of the "Introduction" phase or commissioning phase. Other
mechanisms based on IP destination filtering can be applied by the
controller to all Relay nodes to avoid misuse of the network resources.

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Wed, 28 May 2014 08:14:19 +0000

Hi Rene

The security considerations section is not completely baked yet. But to answer your questions, we were considering the following two threats:
- DoS where a large number of joining messages are sent by  rogue nodes either to flood the lowpan or drain the network manager
- misuse of the relay functionality to allow a rogue node to setup a DTLS session with a server which is not the network manager

The "on/off switch" is just one option for the DoS where the network manager can detect too many failed requests and issue a multicast management message (e.g. a CoAP request to a resource) to stop or further throttle joining messages being accepted by relay nodes for a limited time. Of course as you mentioned, this will be delayed until the third flow of the DTLS protocol, but the DTLS cookie should provide some additional resistance initially. In other scenarios, the timing of a joining device is known (e.g. within a home) and the relays can be asked to switched on and later switched off to restrict the window of opportunity to the attacker.

The idea is that the new device gets the configuration info within the DTLS session that is created (e.g. as a CoAP request to a resource). How and format needs to be defined (either here or somewhere else more generally).

There could be more threats and possible countermeasures, let me know if you have more ideas.

Regards
Sandeep

> -----Original Message-----
> From: dtls-iot [mailto:[email-masked]] On Behalf Of Rene Struik
> Sent: Tuesday, May 27, 2014 10:55 PM
> To: [email-masked]
> Subject: [Dtls-iot] question on draft-kumar-dice-dtls-relay-01
>
> considerations section of that draft, you allude to potential denial of services
> attacks in the context where a one-hop neighbor of a joining node facilitates
> messaging between that joining node and the network manager potentially
> many hops away, where the joining node and the network manager act as
> DTLS Client and DTLS Server, respectively, and where the one-hop neighbor
> acts as DTLS Relay. You also suggest some measures to thwart/limit denial of
> service attack risk.
>
> 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. How would one detect a potential
> DoS attack and turn on the "DTLS Relay on/off" knobs to counter an influx of
> bogus join protocol messages that could be amplified if this would travel to
> the network manager (in a scenario where both are many hops away from
> each other)? Since with DTLS, client authentication only happens in the third
> protocol flow, it seems that by necessity one has to allow three subsequent
> message flows (key establishment messages from client to server and back,
> key confirmation message from client to server), without the DTLS Relay
> element having a mechanism (except for throttling) to cryptographically
> arbitrage these flows.
>
> [excerpt from draft-kumar-dice-dtls-relay-01] 5. Security Considerations
> forwarding of messages from devices through a network to which it has not
> yet been admitted. This can lead to denial-of-service attacks or misuse of
> network resources without proper authentication. One way to overcome any
> large scale misuse of the network is to have a management message from
> the Controller that initiates already authenticated devices in the network to
> enter into a DTLS Relay mode. The devices can stay such a Relay mode for a
> fixed period of time or until the Controller sends a new management
> message blocking the DTLS Relay mode in all devices in the network. This is
> often possible since the administrator of the network can be aware when
> new devices join the network either because of the "Introduction" phase or
> commissioning phase. Other mechanisms based on IP destination filtering
> can be applied by the controller to all Relay nodes to avoid misuse of the
> network resources.
>
> --
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Rene Struik <[email-masked]>
Date: Wed, 28 May 2014 11:10:36 -0400

Hi Sandeep:

Thanks for the quick reply. I do understand your second threat, but not 
how the "on/off switch" would play a role here.

According to Section 3.1, with stateful relay, if the joining node knows 
the DTLS Server's IP address, the DTLS Relay simply forwards this. If 
the joining node does *not* know the DTLS Server's IP address, the DTLS 
Relay is forwarding it to any device it likes (which could of course 
very well be the network manager). So, in the first case the joining 
node seems in full control as to which device it connects (perhaps, even 
a device that is not part of the network); in the second case the 
relaying node determines who it connects the joining node to (which may 
be fine in communication security scenarios, but perhaps not in 
application security settings).

If you could elaborate on the role of the "on/off switch" in countering 
these threats that would help.

Rene

[2nd threat, excerpted from your email as of May 28, 2014, 10:14am NL]

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Wed, 28 May 2014 15:43:07 +0000

Hi Rene

Sorry for the confusion, I did not intend to say that the "on/off" was for the second threat. It only addresses the first threat.

Regarding the second threat, indeed as you mentioned, either the relay node decides or as in the security considerations " Other mechanisms based
on IP destination filtering can be applied by the controller to all Relay nodes to avoid misuse of the network resources." I agree this is vague on how the filtering parameters can be determined which can be extended in future based on the use cases. Do you have any specific use case where a joining node decides which network manager to contact?

Regards
Sandeep

> From: Rene Struik [mailto:[email-masked]]
> Sent: Wednesday, May 28, 2014 5:11 PM
> To: Kumar, Sandeep; [email-masked]
> Subject: Re: [Dtls-iot] question on draft-kumar-dice-dtls-relay-01
>
> Hi Sandeep:
>
> Thanks for the quick reply. I do understand your second threat, but not how
> the "on/off switch" would play a role here.
>
> According to Section 3.1, with stateful relay, if the joining node knows the
> DTLS Server's IP address, the DTLS Relay simply forwards this. If the joining
> node does *not* know the DTLS Server's IP address, the DTLS Relay is
> forwarding it to any device it likes (which could of course very well be the
> network manager). So, in the first case the joining node seems in full control
> as to which device it connects (perhaps, even a device that is not part of the
> network); in the second case the relaying node determines who it connects
> the joining node to (which may be fine in communication security scenarios,
> but perhaps not in application security settings).
>
> If you could elaborate on the role of the "on/off switch" in countering these
> threats that would help.
>
> Rene
>
> - misuse of the relay functionality to allow a rogue node to setup a DTLS
> session with a server which is not the network manager
>
>
> > The security considerations section is not completely baked yet. But to
> answer your questions, we were considering the following two threats:
> > - DoS where a large number of joining messages are sent by  rogue
> > nodes either to flood the lowpan or drain the network manager
> > - misuse of the relay functionality to allow a rogue node to setup a
> > DTLS session with a server which is not the network manager
> >
> > The "on/off switch" is just one option for the DoS where the network
> manager can detect too many failed requests and issue a multicast
> management message (e.g. a CoAP request to a resource) to stop or further
> throttle joining messages being accepted by relay nodes for a limited time.
> Of course as you mentioned, this will be delayed until the third flow of the
> DTLS protocol, but the DTLS cookie should provide some additional resistance
> initially. In other scenarios, the timing of a joining device is known (e.g. within
> a home) and the relays can be asked to switched on and later switched off to
> restrict the window of opportunity to the attacker.
> >
> > The idea is that the new device gets the configuration info within the DTLS
> session that is created (e.g. as a CoAP request to a resource). How and
> format needs to be defined (either here or somewhere else more
> generally).
> >
> >> considerations section of that draft, you allude to potential denial
> >> of services attacks in the context where a one-hop neighbor of a
> >> joining node facilitates messaging between that joining node and the
> >> network manager potentially many hops away, where the joining node
> >> and the network manager act as DTLS Client and DTLS Server,
> >> respectively, and where the one-hop neighbor acts as DTLS Relay. You
> >> also suggest some measures to thwart/limit denial of service attack risk.
> >>
> >> 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. How would one
> >> detect a potential DoS attack and turn on the "DTLS Relay on/off"
> >> knobs to counter an influx of bogus join protocol messages that could
> >> be amplified if this would travel to the network manager (in a
> >> scenario where both are many hops away from each other)? Since with
> >> DTLS, client authentication only happens in the third protocol flow,
> >> it seems that by necessity one has to allow three subsequent message
> >> flows (key establishment messages from client to server and back, key
> >> confirmation message from client to server), without the DTLS Relay
> >> When does the newbee device get configuration info and, e.g., a
> >> routable address assigned?
> >>
> >> [excerpt from draft-kumar-dice-dtls-relay-01] 5. Security
> >> Considerations Additional security considerations need to be taken
> >> into account about forwarding of messages from devices through a
> >> network to which it has not yet been admitted. This can lead to
> >> denial-of-service attacks or misuse of network resources without
> >> proper authentication. One way to overcome any large scale misuse of
> >> the network is to have a management message from the Controller that
> >> initiates already authenticated devices in the network to enter into
> >> a DTLS Relay mode. The devices can stay such a Relay mode for a fixed
> >> period of time or until the Controller sends a new management message
> >> blocking the DTLS Relay mode in all devices in the network. This is
> >> often possible since the administrator of the network can be aware
> >> when new devices join the network either because of the
> >> "Introduction" phase or commissioning phase. Other mechanisms based
> >> on IP destination filtering can be applied by the controller to all Relay
> nodes to avoid misuse of the network resources.
> >>
> >> --
> > The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby notified
> that any use, forwarding, dissemination, or reproduction of this message is
> strictly prohibited and may be unlawful. If you are not the intended recipient,
> please contact the sender by return e-mail and destroy all copies of the
> original message.
> >
>
>
> --

---

From: Rene Struik <[email-masked]>
Date: Wed, 28 May 2014 12:15:49 -0400

With 802.11, when a STA device joins a network at an access point AP, the AP may sometimes act as a relay station and the actual authentication is done by a third-party device T. In 802.11 parlance, I believe the STA is called the supplicant, the AP the Authenticator and T the Server (very confusing verbiage indeed, since AP does not do anything from crypto perspective). In fact, any three-party key agreement protocol with inline third party and where the result really depends on this third party being in the loop seems an example of use case you asked about.

==
Do you have any specific use case where a joining node decides which network manager to contact?

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Wed, 28 May 2014 18:47:46 +0000

In 802.11, if I am not mistaken, the AP acting as the relay decides which authentication server T to use (e.g. which RADIUS server to use is configured at the AP and not on the STA). The STA may indicate a domain parameter if a remote RADIUS server needs to be used but the address of the remote server is configured at the proxy RADIUS server. In both cases the STA cannot contact arbitrary server T. Its similar to the case where the DTLS relay decides which network manager to use. Right?

Sandeep

From: Rene Struik<mailto:[email-masked]>
Sent: ‎Wednesday‎, ‎May‎ ‎28‎, ‎2014 ‎6‎:‎15‎ ‎PM
To: Sandeep Kumar<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

==

---

From: Rene Struik <[email-masked]>
Date: Wed, 28 May 2014 15:31:59 -0400

Hi Sandeep:

(based on recollection of 802.11ai discussions) Conceptually, the 
third-party of the STA and AP may be different from one another (if 
these have pre-established keys with different third-parties). In that 
case, while logically the third-parties are different, this may still 
result in AP communicating with its own third-party and delegating any 
third-party arbitrage stuff to a (for him) black box. (So, communication 
can still be seemingly decided locally by AP alone, with any other 
mechanisms occurring invisibly in the background. With 802.11 wifi in a 
smart phone, third parties of STA and AP could, for example, be Verizon 
and China Mobile, where "black box" magic would be some heavy-handed 
infrastructure and business agreements between those two players.

Of course, this is all slightly on a tangent w.r.t. security aspects of 
relayed communications.

Rene

On 5/28/2014 2:47 PM, Kumar, Sandeep wrote:
> In 802.11, if I am not mistaken, the AP acting as the relay decides 
> which authentication server T to use (e.g. which RADIUS server to use 
> is configured at the AP and not on the STA). The STA may indicate a 
> domain parameter if a remote RADIUS server needs to be used but the 
> address of the remote server is configured at the proxy RADIUS server. 
> In both cases the STA cannot contact arbitrary server T. Its similar 
> to the case where the DTLS relay decides which network manager to use. 
> Right?
>
> Sandeep
>
>
> *From:* Rene Struik <mailto:[email-masked]>
> *Sent:* ‎Wednesday‎, ‎May‎ ‎28‎, ‎2014 ‎6‎:‎15‎ ‎PM
> *To:* Sandeep Kumar <mailto:[email-masked]>, 
> [email-masked] <mailto:[email-masked]>
>
> With 802.11, when a STA device joins a network at an access point AP, 
> the AP may sometimes act as a relay station and the actual 
> authentication is done by a third-party device T. In 802.11 parlance, 
> I believe the STA is called the supplicant, the AP the Authenticator 
> and T the Server (very confusing verbiage indeed, since AP does not do 
> anything from crypto perspective). In fact, any three-party key 
> agreement protocol with inline third party and where the result really 
> depends on this third party being in the loop seems an example of use 
> case you asked about.
>
> ==
> > Sorry for the confusion, I did not intend to say that the "on/off" 
> was for the second threat. It only addresses the first threat.
> >
> > Regarding the second threat, indeed as you mentioned, either the 
> relay node decides or as in the security considerations " Other 
> mechanisms based
> > on IP destination filtering can be applied by the controller to all 
> Relay nodes to avoid misuse of the network resources." I agree this is 
> vague on how the filtering parameters can be determined which can be 
> extended in future based on the use cases. Do you have any specific 
> use case where a joining node decides which network manager to contact?
> >
> > Regards
> > Sandeep
> >
> >
> >>> There could be more threats and possible countermeasures, let me 
> know if
> >> you have more ideas.
> >>> Regards
> >>> Sandeep
> >>>
> > The information contained in this message may be confidential and 
> legally protected under applicable law. The message is intended solely 
> for the addressee(s). If you are not the intended recipient, you are 
> hereby notified that any use, forwarding, dissemination, or 
> reproduction of this message is strictly prohibited and may be 
> unlawful. If you are not the intended recipient, please contact the 
> sender by return e-mail and destroy all copies of the original message.
> >
>
>
> --

---

From: Robert Cragie <[email-masked]>
Date: Thu, 29 May 2014 18:39:37 +0100

Hi Rene,

Regarding the denial of service attack, the aim is to limit the impact 
an unauthenticated device can have on other network devices from the 
point of view of network access.

The simplest countermeasure, which is widely used, is that whereby a 
network-wide "permit join" is in force. This is probably the on/off 
switch alluded to in the security considerations, so I don't think this 
switch works autonomously based on detecting a large amount of 
unauthenticated traffic, although this could be fed in to heuristics to 
decide the state of permit join, especially with regarding to early 
disabling. This is a simple way of preventing any attempt to appropriate 
resources on a node at the perimeter of the network, providing 
unauthenticated traffic can be easily distinguished. An example of 
distinguishing traffic from an unauthenticated node from traffic from an 
authenticated node is the presence of link layer security using a 
network-wide key, given as a network access token. Assuming this method 
is used, the perimeter node would simply silently discard any data 
traffic unsecured at the network layer (excluding handling any necessary 
management commands, e.g. beacon request).

The next level of countermeasure needs to be considered when permit join 
is enabled. In this case, a perimeter node needs to act as an 
enforcement point and carefully police data traffic from any 
unauthenticated node. Assuming the link-layer security method is used, 
it is also easy to distinguish valid traffic for authentication purposes 
from other traffic and to allow only such traffic to be further 
processed. This further processing should ideally consume as little in 
the way of resources as possible at the perimeter node. Hence the 
suggested use of the stateless relay, which ensures there is no need to 
allocate any resources to maintain state for the purposes of relaying to 
another node.

The cookie mechanism also provides some protection using spoofing nodes. 
This could possibly be generalised into a proof of work/puzzle 
mechanism, where a cookie exchange is a very simple proof of work which 
would ask the unauthenticated initiator to do something to prove it is 
at least attempting an authentication handshake.

Further than that, the authentication handshake then of course has to 
complete successfully.

It is the earlier stages which are of interest in the case of the DTLS 
relay and I think it would be worth expanding on these in the security 
considerations.

With regard to the 802.11 model, the AP acts as pass-through 
Authenticator (an EAP expression) to an Authentication Server (usually 
through RADIUS). The EAP model only considers these parties and whilst 
there could be more intermediates, they don't figure as part of the EAP 
transaction. The relay model is somewhat different in that an 802.11 STA 
- AP model is a star (hub and spoke) model, whereas the relay model is 
aimed more at mesh networks, hence the concept of a relay at a perimeter 
node. Therefore it is possible in EAP terms that the joining node is the 
Peer (supplicant in 802.1X-speak), the perimeter node is the relay (not 
an EAP concept), the border router is the pass-through Authenticator and 
some other device outside of the network being accessed is the 
Authentication Server.

Robert

On 28/05/2014 8:31 PM, Rene Struik wrote:
> third-party arbitrage stuff to a (for him) black box. (So, 
> communication can still be seemingly decided locally by AP alone, with 
> any other mechanisms occurring invisibly in the background. With 
> 802.11 wifi in a smart phone, third parties of STA and AP could, for 
> example, be Verizon and China Mobile, where "black box" magic would be 
> some heavy-handed infrastructure and business agreements between those 
> two players.
>
> Of course, this is all slightly on a tangent w.r.t. security aspects 
> of relayed communications.
>
> Rene
>
>> address of the remote server is configured at the proxy RADIUS 
>> server. In both cases the STA cannot contact arbitrary server T. Its 
>> similar to the case where the DTLS relay decides which network 
>> manager to use. Right?
>>
>> Sandeep
>>
>>
>> *Sent:* ?Wednesday?, ?May? ?28?, ?2014 ?6?:?15? ?PM
>> and T the Server (very confusing verbiage indeed, since AP does not 
>> do anything from crypto perspective). In fact, any three-party key 
>> agreement protocol with inline third party and where the result 
>> really depends on this third party being in the loop seems an example 
>> of use case you asked about.
>>
>> ==
>> Relay nodes to avoid misuse of the network resources." I agree this 
>> is vague on how the filtering parameters can be determined which can 
>> be extended in future based on the use cases. Do you have any 
>> specific use case where a joining node decides which network manager 
>> to contact?
>> >
>> > Regards
>> > Sandeep
>> >
>> >
>> legally
>> legally protected under applicable law. The message is intended 
>> solely for the addressee(s). If you are not the intended recipient, 
>> you are hereby notified that any use, forwarding, dissemination, or 
> email:[email-masked]  | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Thu, 29 May 2014 16:19:08 -0400

Hi Robert:

Thanks for your note.

In the scenario where the "permit join" flag is switched ON, the DTLS 
Relay element can indeed limit the impact on locally maintained state by 
"making state travel around" (the stateless relay in Section 3.2 of the 
draft). However, this does not necessarily reduce the impact on consumed 
network resources (e.g., in terms of used capacity) elsewhere. Hence, my 
question on how the "relay on/off" switch mentioned in the security 
consideration section of draft-kumar-dice-dtls-relay-01 would work in 
practice.

I think we all agree that this needs more work.

Rene

On 5/29/2014 1:39 PM, Robert Cragie wrote:
> switch alluded to in the security considerations, so I don't think 
> this switch works autonomously based on detecting a large amount of 
> unauthenticated traffic, although this could be fed in to heuristics 
> to decide the state of permit join, especially with regarding to early 
> disabling. This is a simple way of preventing any attempt to 
> appropriate resources on a node at the perimeter of the network, 
> providing unauthenticated traffic can be easily distinguished. An 
> example of distinguishing traffic from an unauthenticated node from 
> traffic from an authenticated node is the presence of link layer 
> security using a network-wide key, given as a network access token. 
> Assuming this method is used, the perimeter node would simply silently 
> discard any data traffic unsecured at the network layer (excluding 
> handling any necessary management commands, e.g. beacon request).
>
> The next level of countermeasure needs to be considered when permit 
> join is enabled. In this case, a perimeter node needs to act as an 
> it is also easy to distinguish valid traffic for authentication 
> purposes from other traffic and to allow only such traffic to be 
> further processed. This further processing should ideally consume as 
> little in the way of resources as possible at the perimeter node. 
> Hence the suggested use of the stateless relay, which ensures there is 
> no need to allocate any resources to maintain state for the purposes 
> of relaying to another node.
>
> The cookie mechanism also provides some protection using spoofing 
> nodes. This could possibly be generalised into a proof of work/puzzle 
> mechanism, where a cookie exchange is a very simple proof of work 
> which would ask the unauthenticated initiator to do something to prove 
> it is at least attempting an authentication handshake.
>
> there could be more intermediates, they don't figure as part of the 
> EAP transaction. The relay model is somewhat different in that an 
> 802.11 STA - AP model is a star (hub and spoke) model, whereas the 
> relay model is aimed more at mesh networks, hence the concept of a 
> relay at a perimeter node. Therefore it is possible in EAP terms that 
> the joining node is the Peer (supplicant in 802.1X-speak), the 
> perimeter node is the relay (not an EAP concept), the border router is 
> the pass-through Authenticator and some other device outside of the 
> network being accessed is the Authentication Server.
>
> Robert
>
>> these have pre-established keys with different third-parties). In 
>> that case, while logically the third-parties are different, this may 
>> still result in AP communicating with its own third-party and 
>> delegating any third-party arbitrage stuff to a (for him) black box. 
>> (So, communication can still be seemingly decided locally by AP 
>> alone, with any other mechanisms occurring invisibly in the 
>> background. With 802.11 wifi in a smart phone, third parties of STA 
>> and AP could, for example, be Verizon and China Mobile, where "black 
>> box" magic would be some heavy-handed infrastructure and business 
>> agreements between those two players.
>>
>>> which authentication server T to use (e.g. which RADIUS server to 
>>> use is configured at the AP and not on the STA). The STA may 
>>> indicate a domain parameter if a remote RADIUS server needs to be 
>>> used but the address of the remote server is configured at the proxy 
>>> RADIUS server. In both cases the STA cannot contact arbitrary server 
>>> T. Its similar to the case where the DTLS relay decides which 
>>> network manager to use. Right?
>>>
>>> Sandeep
>>>
>>>
>>> With 802.11, when a STA device joins a network at an access point 
>>> AP, the AP may sometimes act as a relay station and the actual 
>>> authentication is done by a third-party device T. In 802.11 
>>> parlance, I believe the STA is called the supplicant, the AP the 
>>> Authenticator and T the Server (very confusing verbiage indeed, 
>>> since AP does not do anything from crypto perspective). In fact, any 
>>> three-party key agreement protocol with inline third party and where 
>>> the result really depends on this third party being in the loop 
>>> seems an example of use case you asked about.
>>>
>>> ==
>>> > on IP destination filtering can be applied by the controller to 
>>> all Relay nodes to avoid misuse of the network resources." I agree 
>>> this is vague on how the filtering parameters can be determined 
>>> which can be extended in future based on the use cases. Do you have 
>>> any specific use case where a joining node decides which network 
>>> manager to contact?
>>> >
>>> > Regards
>>> > Sandeep
>>> >
>>> >

---

From: Robert Cragie <[email-masked]>
Date: Fri, 30 May 2014 10:36:49 +0100

Hi Rene,

The point is to ensure the relay model itself does not introduce state, 
i.e. the net state change between before a DTLS packet is received and 
after it has been relayed is zero. It is not really that easy to 
consider the impact on other network resources as it depends on the 
network type etc. but we can use examples.

In the example given below, if the relay on/off switch is in the OFF 
position, any data packet which is unsecured would be discarded at the 
earliest opportunity during the receive process. This would minimise 
allocation of resources for the purposes of packet processing to simply 
buffering one incoming packet, reading the header then silently 
discarding the packet immediately. One could even imagine an intelligent 
hardware-based MAC doing this based on setting security policy at the 
MAC layer, so the packet may not even be received by the CPU/firmware 
processing the packet.

Robert

On 29/05/2014 9:19 PM, Rene Struik wrote:
> Relay element can indeed limit the impact on locally maintained state 
> by "making state travel around" (the stateless relay in Section 3.2 of 
> the draft). However, this does not necessarily reduce the impact on 
> consumed network resources (e.g., in terms of used capacity) 
> elsewhere. Hence, my question on how the "relay on/off" switch 
> mentioned in the security consideration section of 
> draft-kumar-dice-dtls-relay-01 would work in practice.
>
>> Regarding the denial of service attack, the aim is to limit the 
>> impact an unauthenticated device can have on other network devices 
>> from the point of view of network access.
>>
>> to decide the state of permit join, especially with regarding to 
>> early disabling. This is a simple way of preventing any attempt to 
>> Assuming this method is used, the perimeter node would simply 
>> silently discard any data traffic unsecured at the network layer 
>> (excluding handling any necessary management commands, e.g. beacon 
>> request).
>>
>> unauthenticated node. Assuming the link-layer security method is 
>> used, it is also easy to distinguish valid traffic for authentication 
>> Hence the suggested use of the stateless relay, which ensures there 
>> is no need to allocate any resources to maintain state for the 
>> purposes of relaying to another node.
>>
>> which would ask the unauthenticated initiator to do something to 
>> prove it is at least attempting an authentication handshake.
>>
>> It is the earlier stages which are of interest in the case of the 
>> DTLS relay and I think it would be worth expanding on these in the 
>> security considerations.
>>
>> Authenticator (an EAP expression) to an Authentication Server 
>> (usually through RADIUS). The EAP model only considers these parties 
>> and whilst there could be more intermediates, they don't figure as 
>> part of the EAP transaction. The relay model is somewhat different in 
>> that an 802.11 STA - AP model is a star (hub and spoke) model, 
>> whereas the relay model is aimed more at mesh networks, hence the 
>> concept of a relay at a perimeter node. Therefore it is possible in 
>> EAP terms that the joining node is the Peer (supplicant in 
>> 802.1X-speak), the perimeter node is the relay (not an EAP concept), 
>> the border router is the pass-through Authenticator and some other 
>> device outside of the network being accessed is the Authentication 
>> Server.
>>
>> Robert
>>
>>>> used but the address of the remote server is configured at the 
>>>> proxy RADIUS server. In both cases the STA cannot contact arbitrary 
>>>> server T. Its similar to the case where the DTLS relay decides 
>>>> which network manager to use. Right?
>>>>
>>>> Sandeep
>>>>
>>>>
>>>> since AP does not do anything from crypto perspective). In fact, 
>>>> any three-party key agreement protocol with inline third party and 
>>>> where the result really depends on this third party being in the 
>>>> loop seems an example of use case you asked about.
>>>>
>>>> ==
>>>> > Sorry for the confusion, I did not intend to say that the 
>>>> "on/off" was for the second threat. It only addresses the first threat.
>>>> >
>>>> >>> There could be more threats and possible countermeasures, let 
>>>> me know if
>>>> >> you have more ideas.
>>>> >>> Regards
>>>> >>> Sandeep
>>>> >>>
>>>> >>>> From: dtls-iot [mailto:[email-masked]] On Behalf Of 
>>>> Rene
>>>> >>>> Struik

---

From: Rene Struik <[email-masked]>
Date: Fri, 30 May 2014 10:08:06 -0400

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.

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.

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).

I hope this helps.

Rene

[excerpt of my email as of Tue May 27, 2014, 4:55pm EDT]
 >>>> DTLS Relay "on/off switch" would work in practice

On 5/30/2014 5:36 AM, Robert Cragie wrote:
> Hi Rene,
>
> The point is to ensure the relay model itself does not introduce 
> state, i.e. the net state change between before a DTLS packet is 
> received and after it has been relayed is zero. It is not really that 
> easy to consider the impact on other network resources as it depends 
> on the network type etc. but we can use examples.
>
> allocation of resources for the purposes of packet processing to 
> simply buffering one incoming packet, reading the header then silently 
> discarding the packet immediately. One could even imagine an 
> intelligent hardware-based MAC doing this based on setting security 
> policy at the MAC layer, so the packet may not even be received by the 
> CPU/firmware processing the packet.
>
> Robert
>
>> by "making state travel around" (the stateless relay in Section 3.2 
>> of the draft). However, this does not necessarily reduce the impact 
>> on consumed network resources (e.g., in terms of used capacity) 
>>> used, it is also easy to distinguish valid traffic for 
>>> authentication purposes from other traffic and to allow only such 
>>> traffic to be further processed. This further processing should 
>>> ideally consume as little in the way of resources as possible at the 
>>> perimeter node. Hence the suggested use of the stateless relay, 
>>> which ensures there is no need to allocate any resources to maintain 
>>> state for the purposes of relaying to another node.
>>>
>>> nodes. This could possibly be generalised into a proof of 
>>> work/puzzle mechanism, where a cookie exchange is a very simple 
>>> proof of work which would ask the unauthenticated initiator to do 
>>> something to prove it is at least attempting an authentication 
>>> handshake.
>>>
>>> Further than that, the authentication handshake then of course has 
>>> to complete successfully.
>>>
>>> part of the EAP transaction. The relay model is somewhat different 
>>> in that an 802.11 STA - AP model is a star (hub and spoke) model, 
>>>> that case, while logically the third-parties are different, this 
>>>> may still result in AP communicating with its own third-party and 
>>>> delegating any third-party arbitrage stuff to a (for him) black 
>>>> box. (So, communication can still be seemingly decided locally by 
>>>> AP alone, with any other mechanisms occurring invisibly in the 
>>>> and AP could, for example, be Verizon and China Mobile, where 
>>>> "black box" magic would be some heavy-handed infrastructure and 
>>>> business agreements between those two players.
>>>>
>>>> Of course, this is all slightly on a tangent w.r.t. security 
>>>> aspects of relayed communications.
>>>>
>>>> Rene
>>>>
>>>>> In 802.11, if I am not mistaken, the AP acting as the relay 
>>>>> decides which authentication server T to use (e.g. which RADIUS 
>>>>> server to use is configured at the AP and not on the STA). The STA 
>>>>> may indicate a domain parameter if a remote RADIUS server needs to 
>>>>> be used but the address of the remote server is configured at the 
>>>>> proxy RADIUS server. In both cases the STA cannot contact 
>>>>> arbitrary server T. Its similar to the case where the DTLS relay 
>>>>> decides which network manager to use. Right?
>>>>>
>>>>> Sandeep
>>>>>
>>>>>
>>>>> which can be extended in future based on the use cases. Do you 
>>>>> have any specific use case where a joining node decides which 
>>>>> network manager to contact?
>>>>> >
>>>>> > Regards
>>>>> > Sandeep
>>>>> >
>>>>> >
>>>>> >>>> From: dtls-iot [mailto:[email-masked]] On Behalf 
>>>>> Of Rene
>>>>> >>>> Struik
>>>>> > The information contained in this message may be confidential 
>>>>> and legally protected under applicable law. The message is 
>>>>> intended solely for the addressee(s). If you are not the intended 
>>>>> recipient, you are hereby notified that any use, forwarding, 
>>>>> dissemination, or reproduction of this message is strictly 
>>>>> prohibited and may be unlawful. If you are not the intended 
>>>>> recipient, please contact the sender by return e-mail and destroy 
>>>>> all copies of the original message.
>>>>> >
>>>>>
>>>>>
>>>>> --

---

From: Robert Cragie <[email-masked]>
Date: Fri, 30 May 2014 15:22:58 +0100

Hi Rene,

Comments inline.

Robert

On 30/05/2014 3:08 PM, Rene Struik wrote:
> 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>
> 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>
> 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>
> >>>> DTLS Relay "on/off switch" would work in practice
[snip]

---

From: Rene Struik <[email-masked]>
Date: Fri, 30 May 2014 10:29:46 -0400

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:
> <RCC>It would potentially allow devices to discover networks but not 
> to join them</RCC>
>>
>> newbee device and the relaying station can communicate. So, the 
>> notion of "stateless" may be somewhat a misnomer, at least for sleepy 
> 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>
>>
>> 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).
> 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
>>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 30 May 2014 18:44:36 +0100

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:
> 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.
>
>>> received from newly joining devices does not play. This would also 
>>> be the less interesting scenario, though, since this would not allow 
>>> 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).