Hi John,
Nice job in capturing your thoughts and design ideas.
Few Queries:
1. Socket B: secure, multicast listen for IPv6 and IPv4.
>From your mail, it seems this socket will be bound to port 5684 (coaps secure
>port). And, since it is bound to multicast, it will be listening to traffic
>which is ?un-encrypted?. What kind of traffic are you expecting on this socket?
2. Socket D: secure, unicast send/recv, multicast send for IPv6. ; Socket
F: secure, unicast send/recv, multicast send for IPv4
If these are ?dedicated? secure sockets, I assume the ?data? send or received
on these socket will always be encrypted traffic. Is this a valid assumption?
I am assuming that a socket cannot serve both ?encrypted? and ?un-encrypted?
payload as the other end-point will not be able to figure out if it has to
decrypt the packet or not ??
Below is a brief outline of how ?Security? is currently handled in Iotivity:
+--------------------------+ GET /oic/res
+--------------------------+
| | (multicast resource
discovery request) |
|
|
p:5683|<------------------------------------------------------------------ |
p:6298 Iotivity |
| Iotivity |
|
Client |
| Server | discovery response
| (192.168.1.2)
|
| (192.168.1.1) | (href: /garagedoor; secure: true; port:
5684) | |
|
p:6298|------------------------------------------------------------------> |
p:6298 |
| |
| |
| |
----------------------------------------------------------- |
|
| | Client/Server
creates a secure DTLS channel |
|
| | between
two end-points |
|
| |
(192.168.1.1:5684 --- 192.168.1.2:5684) |
|
| |
----------------------------------------------------------- |
|
| |
| |
| | PUT
request |
|
| | (href: /garagedoor;
lockstatus: open) |
|
| p:5684 |
<----------------------------------------------------------------- | p:5684
|
| |
| |
| |
| |
+--------------------------+
+--------------------------+
Currently, secure port ?5684? is bind without ?SO_REUSEADDR? option and
therefore if another Iotivity stack is started on the same platform, it?s
secure port will be different and that is one of the reasons why ?port? info is
being transferred explicitly during ?resource discovery?.
I would like to understand, how do we intend to resolve discovery and secure
communication between two devices using the proposal which you have suggested.
Thanks
Sachin
503-264-8071
From: iotivity-dev-bounces at lists.iotivity.org
[mailto:[email protected]] On Behalf Of Light, John J
Sent: Wednesday, June 17, 2015 11:20 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] Proposal for IP Adapter and request for feedback
All,
I recently completed the patch titled ?IP address plumbing changes to support
IPv6?. Now I am preparing to provide the IPv6 capability itself. This work
will primarily affect the IP Adapter since the data paths it requires were
handled in the previous patch.
There are two ways to approach the remaining IPv6 work, and I want a feedback
on how this work should be accomplished. I can
? Make a minimal change to the existing IP Adapter code, or
? Simplify the existing code so that adding IPv6 doesn?t make it more
complicated.
Here I will spell out the technical issues involved with the two approaches.
Here is a quick summary of the existing IP Adapter code issues that might
change.
1. Create two sockets for every interface that can support IP addressing,
one each for secure and non-secure connections. These sockets come and go as
network interfaces appear and disappear.
2. A thread dedicated to continually scanning the network interfaces to
maintain a separate list of interfaces for use by the IP Adapter. This happens
every two seconds.
3. The IP Adapter currently allocates non-multicast ports from the range
6298-6307, using a loop to test them for availability.
4. After each message is received, the source address of the message is
tested for being on the same subnet as the interface on which the message was
received. This test involves determining the subnet mask of the associated
subnet and comparing the source and destination addresses in the subnet mask
bits.
Here is how I would simplify the IP Adapter, relating to the above issues
issues.
1. A total of six sockets will be created at IoTivity startup. They will
remain unchanged until shutdown.
a. These are the sockets.
i. Socket
A: non-secure, multicast listen for IPv6 and IPv4.
ii. Socket B:
secure, multicast listen for IPv6 and IPv4.
iii. Socket C:
non-secure, unicast send/recv, multicast send for IPv6.
iv. Socket D:
secure, unicast send/recv, multicast send for IPv6.
v. Socket E:
non-secure, unicast send/recv, multicast send for IPv4.
vi. Socket F:
secure, unicast send/recv, multicast send for IPv4.
b. If the application asks only for IPv6 communication, only Sockets ABCD
are needed.
c. If the application asks only for secure communications, only Sockets
ABDF are needed.
d. Sockets CDEF would be bound to INADDR_ANY so they can handle IP traffic
from any interface, even as interfaces come and go.
2. The network monitor will no longer run on its own thread, and it will
be called only when an multicast is requested.
a. When a multicast is sent, the network monitor will fetch a list of IP
interfaces, and the multicast will be sent to that list.
b. This eliminates the 1-2 second latency between enabling an interface
and being able to use it. This will become more important as 6LoWPAN is
adopted. As soon as the interface is created, it can be used by IoTivity.
c. The use of INADDR_ANY in Sockets CDEF eliminates any further need for
the network monitor.
d. The network monitor no longer needs to call back into the IP Adapter to
update a list, so all the code related to that callback can be eliminated.
3. The IP Adapter will no longer allocate ports other than the CoAP
multicast ports.
a. The ports 6298-6207 are in the range assigned by IANA, and we have no
right to use them. While ports 6298 and 6299 are currently unassigned by IANA,
ports 6300, 6301, and 6306 are assigned, and our use of them is a violation of
network standards.
b. The socket mechanism provides a simple method of assigning ports, and
it?s much simpler. Simply request port 0, and the network will supply a port
which is not used by anyone else.
c. The proposal will implement that simple method, providing standards
compliance and simplifying the code.
4. The testing of subnet masks after receiving messages will be
eliminated.
a. This test accomplishes nothing. Reception of a packet by recvfrom is
ensured by the network layer to include all and only messages to that port.
b. This test consumes considerable resources, involving finding and using
the subnet mask, and requires considerable code.
c. In any case, there is no equivalent code for IPv6, so nothing
equivalent will be provided.
After these changes, the IP Adapter will be much smaller and easier to maintain.
I will say a few words about why I am qualified to make such drastic changes.
I have been programming sockets in both Linux and Windows since about 1990. I
wrote a connectivity abstraction for a commercial product (PC-Xware) in the
early 90s, and contributed to the first two WinSockathons at about that time.
Since then I have used sockets for research projects at Intel.
Please indicate your preference for the direction I should go on the
IoTivity-Dev mailing list by Monday. I will push a patch for IPv6 next week.
If the consensus is for my proposal, I will deliver a patch for it next week.
If not, I will do the obvious patch to the current IP Adapter. If I don?t make
these changes as part of IPv6. I will submit the remainder of the changes in
this proposal as a series of patches over the next few months.
John Light
Intel OTC OIC Development
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150618/9f668c27/attachment.html>
-------------- 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/9f668c27/attachment.p7s>
