Thiago, John and Sachin,
The prevailing thought on this is that the service port is always discovered
(not assumed). If it is always discovered, the unicast port number should not
be an issue. For example, let assume that two instances are on the *same*
device.
Instance #1: Shared multicast port 5683, coap:\\192.168.0.1:5683,
coaps:\\192.168.0.1:5684
Resource A: \light
Resource B: \fan
Instance #2: Shared multicast port 5683, coap:\\192.168.0.1:15683,
coaps:\\192.168.0.1:15684
Resource A: \light
Resource B: \motor
Note that instance #2 has 10000 added to the port number.
When a query for "lights" is preformed, both instances respond from their
resources
Instance #1 reports:
coap:\\192.168.0.1\light
coaps:\\192.168.0.1\light
Instance #2 reports:
coap:\\192.168.0.1: 15683\light
coaps:\\192.168.0.1:15684\light
This assumes that the light resources can be accessed "in the clear" and
securely. If they cannot be accessed "in the clear", the first entry of each
response should be removed. Note that the missing port number means "use the
default port".
Additional comments are inline.
Pat
> -----Original Message-----
> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-
> bounces at lists.iotivity.org] On Behalf Of Agrawal, Sachin
> Sent: Thursday, June 18, 2015 1:28 PM
> To: Light, John J; iotivity-dev at lists.iotivity.org
> Subject: Re: [dev] 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.>>
It would be wrong to assume port. I am not sure what the OIC specification says
about this, but the RFC7252, "6.2. coaps URI Scheme", also reminds us that a
matching IP address differing by scheme should not be considered the same
resource.
> 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 am not sure how secure discovery works in this world. I am aware of secure
multicast, but as I recall the group changes keys each time a member is added
or removed from the group. This implies that they are already aware of each
other, so I am not sure that secured discovery is necessary since membership is
already known.
I might otherwise assume that secure discovery is a combination of multicast
"in-the-clear" to discover devices and 1-to-1 unicast discovery to the secure
port for resource discovery.
> 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.>>
If so, then group membership will be established first, yes?
> 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
>
