On Fri, May 02, 2014 at 11:20:38PM +0200, Jérémie Courrèges-Anglas wrote:
| > I'm not referring to SLAAC.  I'm referring to addresses that are
| > configured on interfaces without the user even requesting them.
| > link-local addresses, specifically.
| 
| I was actually answering your question about link-local addresses.

Fair enough, that wasn't clear to me.

| > Bring up an interface and you
| > have IPv6.  Accessible (and attackable) by everyone on the local
| > network (i.e., not firewalled by default).
| 
| If you have no use for this interface, why do you bring it up?  Why do
| you have services listening on it, be it an IPv4 address or an IPv6
| link-local one?

This is the default behavior from the installer when I install my
machine and pick 'none' for IPv6 addresses, but (e.g.) DHCP for v4.  I
have an SSHD listening on link-local by default.

| > Why do you expect this to
| > work without specific configuration (either setting up a static
| > address, configuring SLAAC, by using DHCPv6, or whatever means)?
| 
| You know why.  This is how v6 works, and I heard OpenBSD made a pretty
| good job at making it work in a pretty safe way.

I know why, I'm challenging the status quo.  And yes, I prefer it to
be OpenBSD, but it still goes against the OpenBSD philosophy.

| > | > I believe your expectation here is wrong (although it is the current
| > | > state of IPv6 on OpenBSD).  Can you explain why you disagree?
| > | 
| > | Not really, I'm puzzled by your question.  It works and has always
| > | worked but I shouldn't expect them to work...
| >
| > I'm puzzled by the fact it has always been this way in OpenBSD.  It
| > goes against the OpenBSD philosophy.
| 
| Maybe it is, or maybe not.  I am not the one that says that (almost?)
| all the IPv6 implementations out there, running ND by default, are
| wrong.  What's the actual impact?  What are the risks?  How do you
| evaluate them?  How much may someone be surprised by this fact?

I think you *are* the one to say that, together with a comunity that
values sane defaults over adhering to bad standards.  If we, as a
group, move in this direction, we can set the example.  How many
systems are running telnetd these days?  This service used to be
enabled by default on many systems, look at history to see how great
an idea that was.  It is OK to question the status quo.

Users may be unaware they are running services accessible over IPv6,
forgetting to do proper filtering in pf, when they specify "none" for
IPv6 addresses in the installer.  The risks seem obvious to me, ssh
scanners present the bulk of logging data on my machines that have ssh
open for the world, 

| > I'll try to rephrase the
| > question:
| >
| >     Why do you expect that you are accessible on IPv6
| >     when you configure an interface with IPv4?  You
| >     don't expect to get IPv4 connectivity when you
| >     configure IPv6, do you?
| 
| Same answer.  The current practice is to run ND and configure
| link-local addresses by default, yet I have to explain why this
| assumption should be valid.  This is tiresome.

"Everybody does it" is an argumentum ad populum.  It's not right
because all systems do this.  All systems do this because some RFC
told them to and apparently nobody considered the downsides (or they
dismissed them).

I'm arguing it should be different since it is unexpected behavior
(keep in mind that you say 'none' to the "IPv6 address for em0? (or
'rtsol' or 'none')" question in the installer - a link-local address
is not "none"), it goes against the OpenBSD philosophy and it exposes
an extra attack surface.

At any rate, you did answer my original question why you'd expect this
behavior (if I read your answer correctly, it is because "that's the
way it is" and "that's what everybody does").  Since you seem annoyed
with the discussion, I'll leave it at that.  Thanks anyway.

Cheers,

Paul 'WEiRD' de Weerd

-- 
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply via email to