Hi John,
I guess my language was not explicit :(.
If we follow the approach suggested by you, an end-point will receive 'packets'
with these possible formats:
[DTLS Header] [DTLS Payload(which can be encrypted or plaintext...but this is
actually immaterial to our current discussion)]
[CoAP Header][CoAp Payload]
Since these headers have no correlation, how can an end-point 'reliably'
differentiate between these packets?
Therefore, does below seems reasonable approach (assuming IPv4 communication)?
(And maybe this is what you meant from the beginning...and I mis-understood it?)
+--------------------------+ GET /oic/res (CoAP packet)
+--------------------------+
| | (multicast resource
discovery request |
|
| | for
secure resources) |
|
|
p:5684|<------------------------------------------------------------------ |
socket E Iotivity |
| Iotivity |
|
Client |
| Server | discovery response
(CoAP Packet) | (192.168.1.2) |
| (192.168.1.1) | (href:
/garagedoor;) |
|
| socket
F|------------------------------------------------------------------> | socket
E |
| |
|
|
| |
----------------------------------------------------------- |
|
| | Client/Server
creates a secure DTLS channel |
|
| | between
two end-points |
|
| | (192.168.1.1:(socket
F) --- 192.168.1.2:(socket F) |
|
| |
----------------------------------------------------------- |
|
| |
|
|
| | PUT
request (DTLS packet) |
|
| | (href:
/garagedoor; lockstatus: open) |
|
| socket F |
<----------------------------------------------------------------- | socket F
|
| |
| |
| |
| |
+--------------------------+
+--------------------------+
Note: 5684 will be bind with 'SO_REUSEADDR' configuration (as does 5683).
Although, in above, 'socket F' is being used to send CoAP packets and DTLS
packets too. Will this cause any issues?
Thanks
Sachin
>-----Original Message-----
>From: Light, John J
>Sent: Thursday, June 18, 2015 10:47 AM
>To: Agrawal, Sachin; iotivity-dev at lists.iotivity.org
>Subject: RE: Proposal for IP Adapter and request for feedback
>
>Sachin,
>
>Mostly we agree or agree to talk. One question merits discussion.
>
>You say "it entails that a secure port 'WILL' receive encrypted and plaintext
>data"
>
>I assumed (incorrectly, possibly) that in the security handshakes and data
>handling, each message is sent with full knowledge of whether the response
>will be encrypted or plaintext data. Then you choose which port to send each
>message on, based on whether you expect an encrypted or plaintext
>response. If so, no port would ever receive both encrypted and plaintext
>data. I don't see how anything works in the current paradigm if my
>assumption is false.
>
>I will mention that I'm dumbfounded to find that CoAP didn't put one
>unencrypted bit on the front of a packet that indicates whether the rest of
>the packet is encrypted or not. Many things would be simpler if they had, and
>I don't understand how one unencrypted bit of this sort would compromise
>security. But I'm not a security guy.
>
>John Light
>Intel OTC OIC Development
>
>
>-----Original Message-----
>From: Agrawal, Sachin
>Sent: Thursday, June 18, 2015 10:28 AM
>To: Light, John J; iotivity-dev at lists.iotivity.org
>Subject: RE: Proposal for IP Adapter and request for feedback
>
>Hi John,
>
>See below for my responses.
>
>Sachin
>
>From: Light, John J
>Sent: Thursday, June 18, 2015 6:15 AM
>To: Agrawal, Sachin; iotivity-dev at lists.iotivity.org
>Subject: RE: Proposal for IP Adapter and request for feedback
>
>Sachin,
>
>Thank you for describing so completely how secure communication works. I
>have some questions for you.
>
>1. If IoTivity stack communicates all secure traffic on 5684, which is not set
>with
>REUSEADDR, how does a second instance (or a non-IoTivity CoAP app) work
>on the same device? With the described usage, the second instance (and
>other secure CoAP applications) will fail. I don?t believe we have the right
>to
>gain exclusive use of the secure CoAP port.
><<SA: Second instance picks up another un-used port for secure
>communication. Although, I do tend to agree with your opinion that ?it
>maybe wrong behavior to use ?5684? exclusively.>>
>
>2. You say ?if another Iotivity stack is started on the same platform,
>it?s
>secure port will be different?. I don?t see how this works in the code. If I
>have
>missed something, it still raises the question of why you use 5684 on the first
>instance of IoTivity, when you can?t use it for the second and third? If we
>can
>securely communicate without exclusive use of 5684 on the second and third
>instances, why can?t that also work on the first?
><<SA: Answered above>>
>
>I assumed (incorrectly, possibly) that the two CoAP ports were both used for
>discovery and initial connection, 5683 for non-secure, 5684 for secure. By
>always unicasting to dynamic port assignments (secure and non-secure), all
>CoAP-based applications can share the same two ports simultaneously.
><<SA: I agree with you here, but as always 'devils are in the details'. So I
>would suggest that let's discuss all use-case scenarios (including
>'collections')
>and then move ahead, if we see this is the best path forward>>
>
>I assumed (incorrectly, possibly) that a CoAP application that wishes to
>communicate securely would discover using 5684 instead of 5683, allowing the
>receiving device to understand the desire for security at the earliest possible
>moment.
><<SA: Yes. But this is not current Iotivity behavior.>>
>
>I assumed (incorrectly, possibly) that a multicast message will be sent from
>the port the multicast receiver should respond to, allowing simple use of
>dynamic unicast ports for all purposes other than discovery.
><<SA: If we work with this assumption, it entails that a secure port 'WILL'
>receive encrypted and plaintext data. I do not believe this is the way 'https'
>works.>>
>
>After you provide answers to the two questions above, I will abandon my
>incorrect assumptions.
>
>John Light
>Intel OTC OIC Development
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7768 bytes
Desc: not available
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150618/7ee7ca3d/attachment.p7s>
