Not obscure, but at least slightly opaque: http://planet.gnu.org/gnutelephony/?p=14 Question: What could be done to reduce the "stand out", or "obviousness" of a SIPWitch node? -- Dean
> Not obscure, but at least slightly opaque: > > http://planet.gnu.org/gnutelephony/?p=14 > > > Question: What could be done to reduce the "stand out", or "obviousness" of a SIPWitch node? P2P SIP comes to mind. Especially if we can use a form of P2P that allows for "local" discovery, without sending traffic to central points. -- Christian Huitema
Hi Christian, On 03/21/2011 10:37 PM, Christian Huitema wrote: >> Not obscure, but at least slightly opaque: >> >> http://planet.gnu.org/gnutelephony/?p=14 >> >> >> Question: What could be done to reduce the "stand out", or "obviousness" of a SIPWitch node? > > P2P SIP comes to mind. Especially if we can use a form of P2P that allows for "local" discovery, without sending traffic to central points. > I am not sure to understand what you mean by local discovery. Can you elaborate? (I plan to release a FOSS implementation of RELOAD this year. I'll let someone else do the SIP part, but I am interested on requirements for the P2P part). Thanks.
Hi Christian,
On 03/21/2011 10:37 PM, Christian Huitema wrote:Not obscure, but at least slightly opaque:
http://planet.gnu.org/gnutelephony/?p=14
Question: What could be done to reduce the "stand out", or "obviousness" of a SIPWitch node?
P2P SIP comes to mind. Especially if we can use a form of P2P that allows for "local" discovery, without sending traffic to central points.
I am not sure to understand what you mean by local discovery. Can you elaborate? (I plan to release a FOSS implementation of RELOAD this year. I'll let someone else do the SIP part, but I am interested on requirements for the P2P part).
_______________________________________________ obscurity-interest mailing list obscurity-interest <at> ietf.org https://www.ietf.org/mailman/listinfo/obscurity-interest
> With a P2P communications architecture it might be possible to discover that people in the local broadcast domain want to hook up. Or to discover that they are injured and require emergency assistance, or that they are fellow emergency responders trying to organize a response.
P2P technologies have an ambiguous relation with privacy. On one hand, P2P avoids reliance on a server that can be compromised or spied upon. On the other hand, it is fairly easy to hack into a P2P cloud and mount attacks such as spoofing, denial of service or spying. Hence my remark about “local” P2P service. If the communication channel can be established without sending packets outside the “local area,” then it becomes somewhat immune to attacks emanating from outside that area.
Thinks to check for, and avoid, include reliance on specific “bootstrap” servers, or reliance on the DNS. I am also skeptical about using too much multicast, even on a local network, as multicast by nature is not very discrete. Thinks to seek, on the other hand, include usage of different channels for bootstrap, e.g. BlueTooth, NSP, or local Wi-Fi, and P2P cloud structures that limit connections to approved parties.
-- Christian Huitema
_______________________________________________ obscurity-interest mailing list obscurity-interest <at> ietf.org https://www.ietf.org/mailman/listinfo/obscurity-interest
Thinks to check for, and avoid, include reliance on specific “bootstrap” servers, or reliance on the DNS. I am also skeptical about using too much multicast, even on a local network, as multicast by nature is not very discrete. Thinks to seek, on the other hand, include usage of different channels for bootstrap, e.g. BlueTooth, NSP, or local Wi-Fi, and P2P cloud structures that limit connections to approved parties.
_______________________________________________ obscurity-interest mailing list obscurity-interest <at> ietf.org https://www.ietf.org/mailman/listinfo/obscurity-interest
RSS Feed