Hi Sandeep,

[Danping] Your understanding is right. In unconstraint environment, Relay Elements simply relay the packets to destination. And as we know, the REs are likely to be constraint devices in constraint environment such as ad hoc WSNs, thus the battery resource and packet buffer will be consumed due to relaying packet for C. In other words, to request resources over a RS that is multiple hops away intrinsically hints a request of the resource over REs along the hops. Therefore I believe the a light AA is desired for the first-hop relay to protect itself and other REs along the route.

Would it not be simple to consider the relay to be an RS which is one-hop away and use the not-yet-designed ACE solution for the first-hop too.

[Danping] It would be better to design a mechanism which allows AM/AS issuing a permission for C to access the first-hop RE, the permission might be transmitted separately or piggybacked with the first AA message between C and RS. The not-yet-designed ACE solution might be used too, but it is unnecessary to exchange key to secure the relay message and the message flow would be different. What do you think?

Regards,

Danping

From: Kumar, Sandeep [mailto:sandeep.kumar@philips.com]
Sent: Wednesday, August 13, 2014 3:24 PM
To: Hedanping (Ana); ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroization messages

HI Danping

According to your solution “The first RE in the path checks whether C holds a valid certificate or a pre-shared relay key” which itself is an authentication/authorization decision. Infact it sounds more like an AA decision to first access the one-hop relay and then an AA decision to access the RS. Would it not be simple to consider the relay to be an RS which is one-hop away and use the not-yet-designed ACE solution for the first-hop too.

Regards

Sandeep

From: Hedanping (Ana) [mailto:ana.hedanping@huawei.com]
Sent: Wednesday, August 13, 2014 2:58 AM
To: Kumar, Sandeep; ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroization messages

Hi Sandeep,

Thanks for the information and also thank you for showing interest in this issue.

The assumption is that, during the AA procedure, there are AA messages exchanged between the C and RS, which are not directly connected. To solve DOS attack, I roughly have a solution in mind:

A relay key/certificate is needed. There might exist more than one RE along the path between C and RS. The first RE in the path checks whether C holds a valid certificate or a pre-shared relay key. If verified, the AA messages from C are relayed normally. Otherwise, the AA messages from C are ignored.

Regards,

Danping

From: Kumar, Sandeep [mailto:sandeep.kumar@philips.com]
Sent: Tuesday, August 12, 2014 4:21 PM
To: Hedanping (Ana); ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroization messages

Hi Danping

I think ACE is at a very early stage that it is better to first solve the problem without the relay path. At a later stage, the relay path can be added for scenarios that might need them and ofcourse DoS protection will be an important issue to consider then. Do you have any specific solutions to solve the problem? If the DoS protection solution depends heavily on the AA data then imho it should be solved in ACE.

Regards

Sandeep

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hedanping (Ana)
Sent: Tuesday, August 12, 2014 5:50 AM
To: ace@ietf.org
Subject: [Ace] About secure relay of authentication and authroization messages

Hi,

There is an issue that I am not sure whether it is suitable for a draft: should we consider secure relay of the Authentication and authorization (AA) messages to protect relay elements along the relay path?

DTLS relay and PANA relay have been proposed, however the relay elements simply relays the AA messages to the server. To avoid DOS attack, the they limit the frequency and maximum number of times to relay the AA requests.

In constraint environment, the relay elements might be energy constrained devices. If a malicious client intends to exhaust the relay elements’ power by frequently sending AA requests with forged IPs or IDs, is there any countermeasure to this issue? Do we need to consider this issue in ACE WG?

Regards,

Danping

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.