Re: [homenet] Understanding DNS-SD hybrid proxying [was: Firewall hole punching]

[Markus Stenberg]

On 23 Nov 2016, at 21.45, Juliusz Chroboczek  wrote:
 - ohybridproxy (only really scalable and sensible IPv6 rdns source that
 I am aware of, given nodes talk mdns)
> 
>>> Noted, thanks for the opinion.  I still don't understand how it works (who
>>> gets port 53?  how are data from multiple links merged?), but I intend to
>>> do my homework.
> 
>> I give dnsmasq port 53, and then have it forward queries for .home
>> (chuckle) and my IPv4/IPv6 reverses in .arpa-land to 127.0.0.1:54 where
>> ohp listens on my routers.
> 
> Ok, makes sense (except for the choice of 54).  Two more questions:
> 
>  - who merges data from multiple links?  (I'd wish that the hybrid
>proxies compute a minimal spanning tree and perform peer-to-peer
>magic, but I suspect you're generating a config file dynamically
>and restarting dnsmasq whenever the set of hybrid proxies changes.)

There is no need for merging, there are only few zones. They are all in DNS-SD 
browse/legacy browse path, and also in DNS search path. The configuration is 
actually static in my case. The benefit of merging is limited as there are only 
few subnets.

>  - who speaks mDNS?  The Hybrid proxies?  Or do they communicate with
>a dedicated mDNS speaker?

ohybridproxy is not a mDNS implementation. I did one once ( 
https://github.com/fingon/hnet-core ) and later on decided it was a bad idea. 
ohp uses patched version of Apple’s mdnsd  ( 
https://github.com/fingon/mDNSResponder ) for heavy lifting.
I haven’t recently checked, but at least at the time Apple’s UNIX version of 
mDNSResponder was essentially broken but I fixed the few bugs that bothered me 
when developing ohp.

Cheers,

-Markus


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Understanding DNS-SD hybrid proxying [was: Firewall hole punching]

[Juliusz Chroboczek]

>>> - ohybridproxy (only really scalable and sensible IPv6 rdns source that
>>> I am aware of, given nodes talk mdns)

>> Noted, thanks for the opinion.  I still don't understand how it works (who
>> gets port 53?  how are data from multiple links merged?), but I intend to
>> do my homework.

> I give dnsmasq port 53, and then have it forward queries for .home
> (chuckle) and my IPv4/IPv6 reverses in .arpa-land to 127.0.0.1:54 where
> ohp listens on my routers.

Ok, makes sense (except for the choice of 54).  Two more questions:

  - who merges data from multiple links?  (I'd wish that the hybrid
proxies compute a minimal spanning tree and perform peer-to-peer
magic, but I suspect you're generating a config file dynamically
and restarting dnsmasq whenever the set of hybrid proxies changes.)

  - who speaks mDNS?  The Hybrid proxies?  Or do they communicate with
a dedicated mDNS speaker?

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Back to Ted's draft [was: Firewall hole punching]

[Juliusz Chroboczek]

> it doesn’t make sense to me why we should spend our time specifying
> protocols for registering names of services in the global domain name
> system unless we have a realistic usage scenario that shows how they
> will be reachable directly by arbitrary public hosts.

Agreed.

> I just don’t see how there is any such realistic scenario. Hence, I’m
> not sold that adopting this draft is a good idea.

I believe that Ted has now clarified that the next version of his draft
will focus solely on naming within the home.  Perhaps I'm optimistic, but
it looks to me like we're slowly converging towards consensus on doing
naming in the home only and ignoring the issues of naming in the Global
Internet.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Firewall hole punching [was: About Ted's naming architecture...]

[Tim Chown]

On 23 Nov 2016, at 15:23, Ca By > 
wrote:



That said, given HOMENET's charter to be the ideal network we always wanted 
without the technical debt, i suggest HOMENET take a strong stance and reject 
"crunchy core, soft middle" security approach.  Meaning, assuming that some 
other device is going to do security for you and you can leave a default 
password telnet open that idea needs to die.

We need to make sure that HOMENET does not have a diagram that says "security 
done here" with an arrow pointed at the gateway.  HOMENET needs to specifically 
mandate all nodes have sane security, and part of that is ripping off the 
band-aid / security blanket of "stateful firewall"... the popular notion that 
stateful firewall does anything meaningful is very damaging to ecosystem... 
mostly because it makes security the responsibility of some other node 
which is not ok.

Part of the “problem” is that the Homenet security architecture is not yet 
documented. It was somewhat punted during the discussions towards RFC 7368, 
with Section 3.6 mentioning RFC 6092 and RFC 4864, without being prescriptive - 
https://tools.ietf.org/html/rfc7368#section-3.6.

I have my doubts that any attempt to flesh that out further now would reach 
consensus, but given we’ve now moved on quite a way, e.g. knowing we have HNCP, 
Babel, etc, and having witnessed Mirai, it might be worth a try. Something for 
the chairs…?

Tim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Firewall hole punching [was: About Ted's naming architecture...]

[Juliusz Chroboczek]

> IoT land [...] there is bit more hope

Joke, right?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Firewall hole punching [was: About Ted's naming architecture...]

[Michael Thomas]

On 11/22/2016 06:54 PM, Lorenzo Colitti wrote:
On Tue, Nov 22, 2016 at 5:34 PM, james woodyatt > wrote:



The recent IoT DDoS publicity is a good example; the devices that
are the Mirai botnet are devices that had/have open ports facing
the internet.


Not quite, c.f.
>

The vast majority of those devices were protected from receiving
inbound flows over public Internet routes by the stateful filters
of IPv4/NAT gateways.


... and this knowledge is not new. The conficker paper 
 from 2009 
found that "144,236 (78.9%) of the infected machines were behind a 
NAT, VPN, proxy, or firewall". We should know this by now :stateful 
firewalls do not protect against malware.


It’s not about reducing attack surfaces. It’s about making systems
that are safe for deployment in close proximity to humans.


+1


I'm glad I'm not the only one who is somewhat dubious of the importance 
of the All Mighty Maginot^H^H^H^H^H^HFirewall in this day and age.
Trivial mobility (eg, phones, etc), for one, really launches big old 
rocks at a firewall's assumption of We and They.


Is there some set of standards/bcp's that describe how, say, a light 
bulb controller can create a completely private network for the light bulbs
that is specifically not routed to the Internet, where that the light 
bulb controller acts as an ALG to those bulbs? That seems more of what I 
want than where
each individual light bulb has to hope that some firewall protects it 
from the mean old internets.


Mike
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Firewall hole punching [was: About Ted's naming architecture...]

[Ca By]

On Tue, Nov 22, 2016 at 11:07 PM, Markus Stenberg 
wrote:

> > On 23 Nov 2016, at 3.34, james woodyatt  wrote:
> > On Nov 22, 2016, at 14:39, Markus Stenberg 
> wrote:
> >>
> >> The recent IoT DDoS publicity is a good example; the devices that are
> the Mirai botnet are devices that had/have open ports facing the internet.
> > Not quite, c.f.  things-under-attack/>
> >
> > The vast majority of those devices were protected from receiving inbound
> flows over public Internet routes by the stateful filters of IPv4/NAT
> gateways.
>
> Interesting. I read somewhere elsewhere that upnp igd was part of the
> problem but not the main one.
>
> > p1. Those ports would not have been open and facing the Internet except
> they were also configured to use UPnP IGD to punch a hole through their
> firewall to expose their unsecured services.
>
> So the default opt-out policy of hole punching is broken.
>
> > p2. More importantly, they were also open and facing other compromised
> hosts on the same network, which were vulnerable not because they had open
> ports facing the Internet but because they were exposed to malware by
> legitimate requests to web servers at public Internet destinations.
>
> I did not read that in that article at least. I can believe infested
> Windows hosts can contaminate anything near them.
>
> > The calls [in both cases p1 and p2] were coming from inside the house.
>
> Default drop inbound policy would have worked in the p1 case; p2 case on
> the other hand, the moment you have someone inside the network, you are
> lost, given the modern software quality.
>
> >> It is all about reducing the attack surface.
> > What attack surfaces were reduced? None of them were turned on at all.
> And why? Because, strangely, the industry in which we work engineers so
> many of the systems, which ordinary people are expected to use, in a way
> that makes them unusable unless all the security mechanisms that reduce the
> attack surfaces are disabled or bypassed by default.
>
> At least based on my reading elsewhere, there is quite a bit of IoT
> hardware that actually has direct IPv4 address as well. And median time to
> infestation is minutes in the current IPv4 land. I also seem to recall that
> the ‘unpatched Windows - time to infestation’ benchmark also was minutes
> already ten years ago. (current Windows has saner default policies though,
> so I am not sure if that is applicable any more.)
>
> > It’s not about reducing attack surfaces. It’s about making systems that
> are safe for deployment in close proximity to humans.
>
> Sounds like an impossible dream then, given how prevalent the default
> username+password has been since 90s. Or buffer overflows. Or SQL injection
> attacks. All of that has been with us 20+ years and seems to be just more
> common, not less common, as the time goes by.
>
> > ... and this knowledge is not new. The conficker paper from 2009 found
> that "144,236 (78.9%) of the infected machines were behind a NAT, VPN,
> proxy, or firewall". We should know this by now :stateful firewalls do not
> protect against malware.
>
> There are also two other potential readings to this;
>
> - the nodes could also move and be infected elsewhere, or
>
> - they can make requests to the outside world with bad actor somewhere in
> the loop. At least earlier, the main _computer_ infection vector were
> essentially humans, who clicked ‘funny picture.exe’ and ignored security
> warnings.
>
> IoT land, there is no human in the loop, so there is bit more hope, given
> software quality is sufficient, as people do not have access to run the
> ‘funny picture.exe’ as root on the devices.
>
>
Yeh, we took the human out of the loop, but with UPnP and PCP, we gave the
malware an API to open the gate.

That said, given HOMENET's charter to be the ideal network we always wanted
without the technical debt, i suggest HOMENET take a strong stance and
reject "crunchy core, soft middle" security approach.  Meaning, assuming
that some other device is going to do security for you and you can leave a
default password telnet open that idea needs to die.

We need to make sure that HOMENET does not have a diagram that says
"security done here" with an arrow pointed at the gateway.  HOMENET needs
to specifically mandate all nodes have sane security, and part of that is
ripping off the band-aid / security blanket of "stateful firewall"... the
popular notion that stateful firewall does anything meaningful is very
damaging to ecosystem... mostly because it makes security the
responsibility of some other node which is not ok.

CB



> Cheers,
>
> -Markus
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org