Mailing List Archive

On 26 September 2016 at 18:30, Tore Anderson <tore@fud.no> wrote:
> * Ted Mittelstaedt
>
>> This kind of mirrors the "default" security policy on IPv4 CPEs (since
>> those CPE's have NAT automatically turned on which creates a "block
>> in, permit out" kind of approach.) so I'm not sure why you would want
>> to default it to being different for IPv6.
>
> There are a gazillion pages out there on the Internet where you'll find
> people trying to figure out how to open ports in their router, make
> their PlayStation or Xbox online gaming Just Work instead of
> complaining about NAT problems, and so on. And this is mostly regarding
> IPv4, where we've already have a solution in the form of UPnP (a
> security nightmare in its own right).
>
> The situation is not exactly user friendly. The IPv4 NATs are making
> applications suffer and people are strugging or failing to work around
> them. We now have the opportunity to do better with IPv6, and I'm
> hoping the ISPs will carefully consider doing so, instead of just
> defaulting to whatever looks the most similar to what they've were
> forced to do for IPv4.
>
> [.I say «forced», because NAT and its intrinsic «drop all inbound» policy
> came about as a way of conserving scarce IPv4 addresses, not as a
> security mechanism. This is obviously not an issue for IPv6.]
>
> So it'd be interesting to see some solid empirical data that explained
> to what extent a default-drop-inbound firewall really increases
> security, and to what extent it impairs applications and thus makes
> users unhappy.
>
> For what it's worth, the Swisscom approach seems sensible to me. At
> least if I understand it correctly, in that they by default only block
> ports associated with application protocols known to be insecure, meant
> for home network use only, etc. All other ports and protocols not on
> the blacklist are let through in both directions. As far as I know this
> has been working out fine for them.
>
> Tore

I think we are probably on the same page - the biggest problem with
the suggestion of an "advanced tab to turn it off" is that my torrent
client doesn't know how to navigate to the advanced tab on the web
interface. It also doesn't understand IPv6 uPnP.

Personally I don't see the need for blocking all inbound connections
on IPv6 as standard practice, it seems that a lot of the justification
is based on "that's how we did it with IPv4, so we need to match that
so we don't reduce security". I would counter that by asking if anyone
remembers the *reason* that IPv4 is the way it is.

No (normal) ISP decided one day that they wanted to block all inbound
traffic on IPv4. Many ISPs put a NAT in the CPE to address address
exhaustion concerns, and this also had the *unwanted* side effect of
breaking inbound connectivty. They had to develop uPnP as a hack on a
hack to reduce the problems this caused.

A residential ISP might have blocked some specific things like 445 -
but why? That example was probably because Windows had security issues
with port 445 and it was easier to block than try and patch every
system, but does that apply to the updated systems that support IPv6?
There was a time where you couldn't even get through the windows
install with an open 445, but that was a long time ago. All the ISPs I
currently have allow 445 over the public internet, and I have a few
windows systems with public IPv4 (and v6 of course) with no firewalls
in front. For the record I have no problem with this kind of targeted
blocking of specific known vulnerabilities, as long as it gets removed
when it is no longer relevant of course.

I guess the point i'm making is that people didn't make a rational
decision block all IPv4 by default, they mostly did it as a side
effect of other decisions. In that case "well that's how we do it on
IPv4" doesn't seem like much of a justification to me.

- Mike

On 9/26/2016 10:30 AM, Tore Anderson wrote:
> * Ted Mittelstaedt
>
>> This kind of mirrors the "default" security policy on IPv4 CPEs (since
>> those CPE's have NAT automatically turned on which creates a "block
>> in, permit out" kind of approach.) so I'm not sure why you would want
>> to default it to being different for IPv6.
>
> There are a gazillion pages out there on the Internet where you'll find
> people trying to figure out how to open ports in their router, make
> their PlayStation or Xbox online gaming Just Work instead of
> complaining about NAT problems, and so on. And this is mostly regarding
> IPv4, where we've already have a solution in the form of UPnP (a
> security nightmare in its own right).
>
> The situation is not exactly user friendly.

I DO NOT see a problem with this and I will explain why a bit later.

> The IPv4 NATs are making
> applications suffer and people are strugging or failing to work around
> them. We now have the opportunity to do better with IPv6,

We have an opportunity to screw it up worse.

> and I'm
> hoping the ISPs will carefully consider doing so, instead of just
> defaulting to whatever looks the most similar to what they've were
> forced to do for IPv4.
>
> [.I say «forced», because NAT and its intrinsic «drop all inbound» policy
> came about as a way of conserving scarce IPv4 addresses, not as a
> security mechanism. This is obviously not an issue for IPv6.]
>
> So it'd be interesting to see some solid empirical data that explained
> to what extent a default-drop-inbound firewall really increases
> security, and to what extent it impairs applications and thus makes
> users unhappy.
>
> For what it's worth, the Swisscom approach seems sensible to me. At
> least if I understand it correctly, in that they by default only block
> ports associated with application protocols known to be insecure, meant
> for home network use only, etc. All other ports and protocols not on
> the blacklist are let through in both directions. As far as I know this
> has been working out fine for them.
>

Until someone invents a new application that uses new ports and has bugs
in it. Or an app that seeks new ports because it thinks others are
blocked.

I do my own auto repairs, and my own home repairs, and my own
electrical and plumbing and painting and so on, so I will tell a story
here that attempts to illustrate some things about the society we live
in that relates to this issue.

Back in the 1960's we had vehicles in the US that just had an engine,
and transmission, and mechanically controlled carburetor. You could
adjust the mixture very easily to make your car more powerful (and
polluting) just change the jets and turn the idle screw.

But, as time went on we decided as a society that making it this easy
to tamper with the engine mixture (and thus get more power and pollute
more) may have resulted in a small benefit for the vehicle owner but
at a large expense to society.

So we first started fitting carbs with anti-tamper caps on the idle
mixture screws (since the idle circuit is used at half-throttle so
fiddling with this gave you a power boost until you hit WOT in which
case you had to change jets)

Then we put computer-controlled carbs on cars which took more effort
to defeat, the usual method was to replace the intake manifold and
carb with aftermarket mechanical

Then we got rid of that and put engine computers on, and later on
we removed all mechanical systems and just had the computer do
everything.

It is still possible of course, to adjust the mixture and get more
power but you have to do it by spending a lot of money and replacing
your engine computer and also it will destroy your catcon. Today,
just about all backyard mechanics can no longer do this so they
content themselves with attaching "fart cans" to the exhausts of
their cars and telling themselves they are getting 10 extra horsepower
that way.

In short, because automobiles were so successful, the industry had to
make them so complicated to work on that the only people who are NOT
professional mechanics who can still work on them, are lost causes like
me who isn't a professional mechanic yet I have $10,000 worth of tools
in my garage along with a 60 gallon shop air compressor, that I've
collected over 30 years, many of those tools are complete specialty ones
that cost several hundred bucks to buy and were used 1 time for 1
specific job on a car that I probably drove into the ground and sold
to a wrecker a decade ago.

The auto industry considers this a roaring success because today, the
barnyard "mekaniks" cannot tamper with their cars and thus release
clouds of pollution, and the few skilled people like me who aren't
safely under the wing of a business somewhere that's scared to death
of violating laws (and thus prohibits their mechanics from tampering)
are educated enough to know that tampering is just going to make the
car run slower and ruin systems in it, and we don't want to spend
$500-$1000 to do it the right way and end up with an actual gain of
10 HP for that money. So, we repair our cars exactly the way a
professional would repair it. (actually most of the time we do a
better job of it because we don't cut corners but that's a different
story)

So, that is the story. Now, here is how I think it applies to the
ISP industry.

ISPs need to understand that the Internet today is mission-critical for
a great many people out there who AREN'T their customers - and they need
to step up to the plate like the auto industry has done.

Allowing your customers to EASILY setup xboxes and other such nonsense
when they don't know what they are doing, well that can cause impacts
far, far, far beyond your own little customer base.

You have a responsibility to the rest of the Internet that is, I
believe, equal to your responsibility to your customers.

Your responsibility is to make tampering with the CPE difficult
for the ignorant.

If one of your customers is hell-bent on setting up their own servers,
they are going to throw out your CPE and find a different one if you
make your CPE such that they cannot just turn off all the firewalling.
So in that case your responsibility to your customer, to supply a
CPE that can have all the firewalling turned off, is the highest.

BUT, if one of your customers is too CHEAP to buy their own router,
and they are too IGNORANT to safely configure your CPE, and too
OBSTINATE to spend the time learning how to safely open ports - well
then the responsibility there to protect the rest of us on the
Internet from your cheap, ignorant, obstinate customer outweighs
any responsibility you have to your customer to make it easy for
them to be cheap, ignorant, and obstinate - and annoy the rest of
us.

Because if they cannot take the time to LEARN how to do it right,
then why would you expect them to keep a server patched so that it
does not become a mule for some nasty cracker out there to attack
us?

This is WHY I am saying that the current situation of making it
difficult to troubleshoot network issues on a CPE is a GOOD THING.

High Tech has figured this out with a great many other things - this
is why now that you have to really know what you are doing and have
special tooling to replace the battery in your cell phone. These
bits of tech are being taken for granted and causing problems when
they are mishandled. So we make them complicated to use to defeat
the nincompoops who don't know what they are doing.

I will leave you with a TIMELESS message I think you should take
to heart:


ACHTUNG!ALLES TURISTEN UND NONTEKNISCHEN LOOKENPEEPERS!DAS
KOMPUTERMASCHINE IST NICHT FÃœR DER GEFINGERPOKEN UND MITTENGRABEN!
ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND
POPPENCORKEN MIT SPITZENSPARKEN.IST NICHT FÃœR GEWERKEN BEI DUMMKOPFEN.
DER RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN HÄNDER IN DAS
POCKETS MUSS.ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.


https://en.wikipedia.org/wiki/Blinkenlights



Ted



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

On 9/25/2016 12:08 AM, erik.taraldsen@telenor.com wrote:
> 1) In theory you are right. In practise it is not that black and
> white. We never buy an excisting product, we buy an future product
> which has to be developed for us. That include physical features
> which may not have beed release from Broadcom yet (11ac 3x3 we were
> the first mass order from Broadcom for example). That means that we
> usualy have an development periode with the vendor, and a release
> target (VDSL launch for example) Sometimes the have to rush the CPE
> side to meet the network side launch. This again means that we
> usualy launch with a fair number of bug and un-optimized software,
> and features missing. And since we don't buy in Comcast type volumes
> we don not have the purchasing power to instruct the vendors to do
> absolutly everything, we have an limited development team working for
> us and we have to prioritize what they should work on. And so far
> UPnP has not gotten above that treshold.
>

Well there is an answer to that. Instead of paying your development
team to do a from-scratch build, you can just have them port over
dd-wrt or openwrt. Both of these router firmwares are most likely
tremendously advanced over anything your CPE development team can
come up with.

Also in the case of dd-wrt you can also pay the dd-wrt developer to
do this. He has done it for other CPE vendors and will sign NDAs
and such if you are using hardware that is so precious that the
vendor won't release programming data for it.

>
> 2) You may have more luck with your forum posts, but on the norwegian
> forums the loudest answer wins the day. Reason cannot stand up to the
> forces of loud ignorance.
>

No, the post that WORKS always ends up winning. You may not have the
last word on a blog but having the last word isn't a sign of winning.

> 3) As stated in 1, limited recources dictates that we prioritice
> security, features which support payable services, then the stuff we
> network geeks want. And since I do know a lot of smaller ISP's and
> retailers of off-the-shelf products, I do know that those products do
> very seldom get anything other than bug fixes for anything other that
> flaws which may refelct badly on the CPE vendor.
>
> 4) The customers are paying for internet access. That used to mean
> an ethernet port and two IPv4 addresses. Today the costomers define
> it as wifi access on the phone in the room the furthest away from the
> router. The level of knowledge in the user base is dropping like a
> stone. If we can have an technical solutin which prevents the
> customer from having issues and calling us, we go for it.
>

There is no such solution because networking and the Internet is
becoming more complex by the day.

I am sorry about this but there you have it. The largest ISPs out there
are solving the support issue by basically offering no useable support,
the customer calls in, complains something doesn't work and is told
to go away and find someone else to help them. These ISPs know that
no matter how angry the customer gets with a non-answer, that ultimately
the customer knows if they quit service and go to another large
competitor that the other large competitor is going to treat them
exactly the same way - so they don't benefit by quitting service.

I make a living today by fixing problems for people who have gotten
non-answers from ISPs for their problems. (among other things) I can
tell you that more and more customers are figuring out that just like
fixing a car, the manufacturer isn't going to train you how to fix your
car you are going to have to take it to a garage and pay someone to fix
it. And yes I agree customer expectations have risen. That is just
bringing the day closer that customers quit bothering the service
providers with problems on their own network. As a former DSL service
provider and a current e-mail service provider I can tell you that
this direction is really the best for both the customer and the
service provider.

Ted


>
> -Erik
>
>
> ________________________________________ Fra:
> ipv6-ops-bounces+erik.taraldsen=telenor.com@lists.cluenet.de<ipv6-ops-bounces+erik.taraldsen=telenor.com@lists.cluenet.de>
> på vegne av Ted Mittelstaedt<tedm@ipinc.net> Sendt: 20. september
> 2016 18:52 Til: ipv6-ops@lists.cluenet.de Emne: Re: SV: CPE
> Residential IPv6 Security Poll
>
> Erik,
>
> I think you have to follow these precepts (keep in mind this is an
> American capitalist perspective not a European cooperative socialist
> perspective)
>
> 1) You got the money, tell your vendors to either do what you want
> (put IPv6 UPnP in CPEs they sell you) or you are going to kick their
> ass. It's your money! They want your money do they not? That's why
> they are selling CPEs to you - so why do you tolerate any crap from
> them? Tell them either put UPnP in the code or your going elsewhere
> for your CPEs and you are going to tell all your other ISP friends to
> go elsewhere for their CPEs. Enough Mr. Nice Guy.
>
> 2) It's not your problem if Ma& Pa Kettle find a wannabe power
> user. If you don't like being bad-mouthed by wannabe power users on
> the online forums then get your ass on the online forums and start
> engaging. Refute those "need bigger antennas" posts with logic and
> reason. I guarantee to you that 1 correct post is worth 100 baloney
> posts from wannabe power users.
>
> 3) How on Earth can you make the case that your ISP router patches
> security holes and adds features yet turn around and claim that you
> can't push your CPE vendors to add UPnP support? Either you have
> power to get your CPE vendors to issue updates or not. If you do -
> then quit complaining that no CPE's have UPnP support for IPv6. If
> you don't - then quit claiming your CPE is better.
>
> 4) What is your customers perception that they are paying for and
> what are they REALLY paying for? If they think they are paying for
> access only - and you think they are paying for access plus your
> management of their network CPE - then I can see why you might be
> wondering why they aren't complaining to you when there's a problem
> and going to the wannabe power users. Maybe you just need to do
> some more customer education?
>
> Ted
>
> On 9/20/2016 1:24 AM, erik.taraldsen@telenor.com wrote:
>> With all due respect to the actual power user out there. For each
>> one of them, there is at least 20 who think they are power users
>> who base their knowledge on rumors and misconceptions. They are
>> often vocal (forums and coments on news sites) and they are the
>> once who often are enlisted to help Ma& Pa Kettle. At least that
>> is what we see a lot of in Norway. They simply do not have the
>> ability to correctly diagnose the issues. Solutions often involve
>> "you need bigger antennas on the router", "Apple routers are
>> allways the best", "the ISP supplied router allways suck".
>>
>> So Bob-the-power-user buy the expencive huge antenna router and
>> install at M&PK. It does not have dual stack, therefore the
>> application at M&PK therefore never tries IPv6 and the older UPnP
>> solution works for them. Bob gets an re confrimation that big
>> antenas helps, and that the ISP router sucks. Where a simpler and
>> cheeper solution would be to modify the firewall settings of the
>> ISP router.
>>
>> Since I reprecent the ISP and spesificaly the ISP supplied router
>> (where we do patch security flaws, add features, optimise DSL and
>> wlan drivers, attack bufferbloat and give the customers the
>> posibility of remote support. Unlike a lot of retail products
>> which often have to live with the software it was shiped with).
>> How do we set up the routers IPv6 setting in such a way that
>> Bob-the-power-user do not have to be called in by M&PK to fix their
>> broken app/network, but still maintain a level of security for
>> them? Is some sort of balanced the way to go? Should we again
>> push our vendors for PCP/UPnP support?
>>
>>
>>
>> -Erik
>>
>>
>> ________________________________________ Fra:
>> ipv6-ops-bounces+erik.taraldsen=telenor.com@lists.cluenet.de<ipv6-ops-bounces+erik.taraldsen=telenor.com@lists.cluenet.de>
>> på vegne av Ted Mittelstaedt<tedm@ipinc.net> Sendt: 19. september
>> 2016 23:23 Til: Bjørn Mork Kopi: ipv6-ops@lists.cluenet.de Emne:
>> Re: CPE Residential IPv6 Security Poll
>>
>> I can tell you that -today- in my location both CenturyLink and
>> Comcast (giant ISPs) supply IPv6 by default on their residential
>> CPEs - and both of those CPEs have "inbound block outbound allow"
>> on by default on IPv6. As far as I know neither support UPnP on
>> IPv6
>>
>> I think you are overthinking this. If a CPE has no IPv6 support
>> but it has UPnP support over IPv4 then things "work" If a CPE has
>> IPv6 support but no UPnP support over IPv6, then things are also
>> going to "work" - on IPv4. They may break on IPv6 with a "block
>> everything" IPv6 rule in which case the end user is undoubtedly
>> going to complain to the toaster manufacturer not you, and that
>> toaster maker is either going to tell their customer "disable ipv6
>> on your ISP CPE" or they are going to fix their toaster so that it
>> doesn't try using UPnP over IPv6, only IPv4.
>>
>> Your job is to not assume your customers are all morons. It is to
>> make it safe for the ones who are, and make it usable for the ones
>> who aren't and want to run their own show. Provide the needed
>> buttons in the CPE to enable or disable IPv6 and to allow your
>> customers to shut off your CPE's interference and be done with it.
>>
>> As an ISP you of all people should understand how powerful the
>> Internet is. If you make your stuff configurable for power users,
>> and document it, then the Ma& Pa Kettle customers are going to
>> engage their friend's son who IS a power user and can search the
>> Internet and follow simple directions and fix their problem with
>> their web cam or whatever it is that is demanding UPnP.
>>
>> If however you default to open, then when Ma& Pa Kettle
>> eventually get cracked, and call in the power user, that power user
>> is going to discover your default firewall on IPv6 is open and
>> realize that you created a huge whole bunch of work for him since
>> he will now have to put back together a PC for the morons. He
>> isn't going to appreciate that and will badmouth you online.
>>
>> Nobody with brains is going to go online and badmouth an ISP that
>> supplies a CPE that has defaults that error on the side of
>> protection-of-morons. But they are going to badmouth an ISP that
>> supplies a CPE that has defaults that allow morons to get easily
>> broken into - because it's them who are going to be sucked into
>> putting those systems back together. And they are really going to
>> badmouth an ISP that supplies a CPE that can't have it's internal
>> firewall turned off.
>>
>> Ted
>>
>> On 9/19/2016 1:29 PM, Bjørn Mork wrote:
>>> Ted Mittelstaedt<tedm@ipinc.net> writes:
>>>
>>>> This kind of mirrors the "default" security policy on IPv4 CPEs
>>>> (since those CPE's have NAT automatically turned on which
>>>> creates a "block in, permit out" kind of approach.) so I'm not
>>>> sure why you would want to default it to being different for
>>>> IPv6.
>>>
>>> I was explained one reason today: No CPEs implement UPnP support
>>> for IPv6 [1].
>>>
>>> This makes the effect of the similar IPv4 and IPv6 policies
>>> quite different. UPnP aware applications will set up the
>>> necessary NAT rules for IPv4, allowing inbound connections etc.
>>> But if you want the same applications to work over IPv6, then the
>>> policy must be more open by default. Letting the user disable
>>> IPv6 filtering is not going to help the masses I'm afraid...
>>>
>>> So the question remains: What do ISPs actually do to - allow
>>> IPv6, and - secure the end users' networks, and - not break dual
>>> stack applications wanting incoming connections
>>>
>>> all at the same time? Looks like a classical "pick any two".
>>>
>>>
>>>
>>> Bjørn
>>>
>>> [1] I'm sure someone will come up with an obscure and expensive
>>> example of the contrary - the point is that IPv6 UPnP support is
>>> not readily available in the residential CPE market.
>>
>> --- This email has been checked for viruses by Avast antivirus
>> software. https://www.avast.com/antivirus
>>
>
> --- This email has been checked for viruses by Avast antivirus
> software. https://www.avast.com/antivirus
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

So lowest common denominator it is then. Of course, any user's home
device can be infected through a web page and become part of a botnet.
Sounds like the right level of internet access is actually just *no*
internet access whatsoever...and we can all go home.

- Mark

> On Sep 27, 2016, at 10:06, Erik Kline <ek@google.com> wrote:
>
> So lowest common denominator it is then. Of course, any user's home
> device can be infected through a web page and become part of a botnet.
> Sounds like the right level of internet access is actually just *no*
> internet access whatsoever...and we can all go home.

On Mon, 26 Sep 2016, Ted Mittelstaedt wrote:

> Well there is an answer to that. Instead of paying your development
> team to do a from-scratch build, you can just have them port over dd-wrt
> or openwrt. Both of these router firmwares are most likely tremendously
> advanced over anything your CPE development team can come up with.

I've been working with this for the past 3 years or so. We have a CPE
using OpenWrt we use as development platform.

So while OpenWrt is great for supporting development of new protocols,
it's nowhere near as stable/bug free as one of the more restrictive vendor
CPEs. When you have millions of devices in the field, shipping OpenWrt
with all the bells and whistles available would be just a nightmare. If
one were to restrict it a lot and just use the features "needed", then it
might be managable. I know some vendors who do this and ship HGWs based on
OpenWrt. It's however quite heavily modified OpenWrt from what I can tell,
and they don't rev their versions as fast as the OPenWrt project does.

> I am sorry about this but there you have it. The largest ISPs out there
> are solving the support issue by basically offering no useable support,
> the customer calls in, complains something doesn't work and is told to
> go away and find someone else to help them. These ISPs know that no
> matter how angry the customer gets with a non-answer, that ultimately
> the customer knows if they quit service and go to another large
> competitor that the other large competitor is going to treat them
> exactly the same way - so they don't benefit by quitting service.

90% (or more) of people want their ISP to just "FIX IT! FIX IT! FIX IT!".
So we're going to see more and more ISP provided equipment in peoples
homes and ISPs getting more and more involved in running the home
networks.

This is not something the ISPs are generally great at, the product cycles
are generally long, it's quite a lot of "let's come up with something that
works, is fairly bug free, then run the production line for 3 years, oh,
and we need to support it for another 3-5 years". This is not a great
combination with some customers wishes to always have the latest and
greatest. Very few people give any kind of love to their "home router".
They go and buy a USD40 device (or complain to the ISP that it's too
expensive when the ISP wants to charge that kind of money for it) and then
they connect their 1000 USD iPhone to it and expect everything to work
great.

But I also (I think we're in agreement here) think I am seeing people more
interested in their home networks now compared to 5-10 years ago. More
people now know that you shouldn't put your wifi router in the basement
behind a lot of boxes if you want good wifi coverage. But there is more to
be done here, and we need more tools to help the customers figure out
what's wrong. Doing truck rolls to fix peoples home networks is going to
be too expensive, so we need home network devices (and SoHo devices) to
talk to each other so they can figure out what's going on and give advice
to the customer. Right now I see forum posts all the time with people
frantically kicking all the things to try to figure out what's going on.
There is no indication to them if the connectivity is bad because the
problem is in their home network, on the access line, ISP core network, or
further out from the Internet. People just don't have the tools to help
them understand what's going on. The only thing they can say is "my
Internet is slow", which of course says nothing what the problem really
is. Current devices can't even tell them if DNS lookups are slow, if TCP
establishment is slow, if TCP transfer rate is low because of packet loss,
because of high delay, because of something else. This information just
isn't available to the end user, and it's sad state of affairs.

The IETF, vendors and ISPs are all quite siloed so I don't know where we
would start to actually improve this. I tried talking to the TCP people at
the IETF and had no takers. I tried talking to the IPPM people, but they
just want to measure with test traffic. I don't know who to talk to next.

--
Mikael Abrahamsson email: swmike@swm.pp.se

Hi,

On Tue, Sep 27, 2016 at 05:06:54PM +0900, Erik Kline wrote:
> So lowest common denominator it is then. Of course, any user's home
> device can be infected through a web page and become part of a botnet.

Nah, of course not. Viruses and such never spreads through mail, or
users clicking on things.

We've heard a long and elaborate explanation that Firewalls on CPEs will
protect IoT devices, so it must be right!

*sigh*

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi,

> For what it's worth, the Swisscom approach seems sensible to me. At
> least if I understand it correctly, in that they by default only block
> ports associated with application protocols known to be insecure, meant
> for home network use only, etc. All other ports and protocols not on
> the blacklist are let through in both directions. As far as I know this
> has been working out fine for them.

I like that approach as well. It might be generalised into "ports <= x are blocked by default and can be opened manually, ports > x are open by default". Whether x=1024, x=10000 or x=16384 can be discussed. If usually services aren't listening on those high-numbered ports then the firewall blocking incoming packets for them doesn't make much of a difference anyway.

Cheers,
Sander

This is a flawed "argument of futility"

The reality is that people are fundamentally lazy -
if they were hard workers and industrious they wouldn't be
trying to make a living off the backs of other people's work.
They wouldn't be stealing and the ones not stealing wouldn't be
taking the lazy way out in a debate and using faulty logic.
Nor would they be trying to use IPv4 because it's simpler
to understand, instead of using IPv6 - which is the reason
this list exists in the first place.

Because of this we know criminals will always take the easiest way
into a system first. When that way gets closed off then they will
take the next easiest way in, and so on and so on. Crime is
one of the most logical businesses in existence - it's immoral
as hell - but you have to respect the logic of a bank robber -
where else do you get $20,000 for 20 minutes of work?

As a result, securing an open system generally happens through
the mechanism of you close a hole then another is discovered and
you close that one and another is discovered and so on and so on.

People who are not well versed in security,
as they see hole after hole closed, they tend to get the idea
that holes are endless. Thus, enters in the "argument of futility"

What they don't understand is that every time a security
hole is discovered it makes it harder and more expensive to attack
the next one.

Because the entire point of crime is laziness, the issue isn't whether
or not we can create an impregnable system. We cannot do that.

The issue is can we make a system that is difficult enough to
break into that the effort of breaking into it is greater than
the effort of just getting a real job and making money the old
fashioned way - by EARNING it, rather than stealing it.

It is easier to attack a system directly that is exposed then
it is to attack that system via proxy. Everyone on the Internet
who produces devices that are used on the Internet has a
responsibility to close holes they create - but they also have a
responsibility to make it difficult for crackers.

The web browser makers use
technology like Smartscreen Filter, Phishing and Malware Protection,
Block Attack Sites & Web Forgeries to try and do their part, the
CPE makers need to do their part, and last and most importantly,
all of us need to continue our efforts to try and educate Ma and
Pa Kettle not to click on the Make Money Fast, schemes.

Ted

On 9/27/2016 12:54 PM, Gert Doering wrote:
> Hi,
>
> On Tue, Sep 27, 2016 at 05:06:54PM +0900, Erik Kline wrote:
>> So lowest common denominator it is then. Of course, any user's home
>> device can be infected through a web page and become part of a botnet.
>
> Nah, of course not. Viruses and such never spreads through mail, or
> users clicking on things.
>
> We've heard a long and elaborate explanation that Firewalls on CPEs will
> protect IoT devices, so it must be right!
>
> *sigh*
>
> Gert Doering
> -- NetMaster

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

On 9/27/2016 1:40 AM, Mikael Abrahamsson wrote:
> On Mon, 26 Sep 2016, Ted Mittelstaedt wrote:
>
>> Well there is an answer to that. Instead of paying your development
>> team to do a from-scratch build, you can just have them port over
>> dd-wrt or openwrt. Both of these router firmwares are most likely
>> tremendously advanced over anything your CPE development team can come
>> up with.
>
> I've been working with this for the past 3 years or so. We have a CPE
> using OpenWrt we use as development platform.
>
> So while OpenWrt is great for supporting development of new protocols,
> it's nowhere near as stable/bug free as one of the more restrictive
> vendor CPEs. When you have millions of devices in the field, shipping
> OpenWrt with all the bells and whistles available would be just a
> nightmare. If one were to restrict it a lot and just use the features
> "needed", then it might be managable.

That's what I have been arguing for. If they only have the ability to
configure their CPE with a web browser and they cannot ssh into an
openwrt command prompt and do anything with it, then IMHO they don't
have the need to go mucking about with a web interface that makes it
easy for them to shoot themselves in the foot.

> I know some vendors who do this
> and ship HGWs based on OpenWrt. It's however quite heavily modified
> OpenWrt from what I can tell, and they don't rev their versions as fast
> as the OPenWrt project does.
>

You should look at dd-wrt also, the effort on it is quite different
than openwrt it's not just "another openwrt"


>> I am sorry about this but there you have it. The largest ISPs out
>> there are solving the support issue by basically offering no useable
>> support, the customer calls in, complains something doesn't work and
>> is told to go away and find someone else to help them. These ISPs know
>> that no matter how angry the customer gets with a non-answer, that
>> ultimately the customer knows if they quit service and go to another
>> large competitor that the other large competitor is going to treat
>> them exactly the same way - so they don't benefit by quitting service.
>
> 90% (or more) of people want their ISP to just "FIX IT! FIX IT! FIX
> IT!".

90% of more of people want to do the cheapest thing. If they can con
their ISP into fixing for free what they would normally have to pay
to have done, they will TRY that first.

> So we're going to see more and more ISP provided equipment in
> peoples homes and ISPs getting more and more involved in running the
> home networks.

I disagree this is what's going to happen. The larger ISP's around
here, at any rate, have figured this out and started to tightly define
what they will do. Sure, they add wifi into their CPEs. But, they
restrict their CPEs down so badly that you can't do anything interesting
with them. That's fine for Ma and Pa Kettle and that's what I think
they should be doing - as long as they leave a button that can be pushed
to turn everything off on the CPE so the customer can use their own
ethernet-to-ethernet router.

I do not see any real interest by any of the large ISPs in getting
further into the home. The reality is that by adding wifi they have
actually withdrawn somewhat from the home network. Now with wifi
they don't have to deal with ethernet chipset incompatibilities because
some customer found an old dumb ethernet hub in someone's garbage
and dragged it home expecting to use it.

>
> This is not something the ISPs are generally great at, the product
> cycles are generally long, it's quite a lot of "let's come up with
> something that works, is fairly bug free, then run the production line
> for 3 years, oh, and we need to support it for another 3-5 years". This
> is not a great combination with some customers wishes to always have the
> latest and greatest. Very few people give any kind of love to their
> "home router". They go and buy a USD40 device (or complain to the ISP
> that it's too expensive when the ISP wants to charge that kind of money
> for it) and then they connect their 1000 USD iPhone to it and expect
> everything to work great.
>
> But I also (I think we're in agreement here) think I am seeing people
> more interested in their home networks now compared to 5-10 years ago.

Yes, probably because as time passes the young 10 year old grandsons are
growing up.

> More people now know that you shouldn't put your wifi router in the
> basement behind a lot of boxes if you want good wifi coverage. But there
> is more to be done here, and we need more tools to help the customers
> figure out what's wrong.

hear hear!! Well said!

> Doing truck rolls to fix peoples home networks
> is going to be too expensive, so we need home network devices (and SoHo
> devices) to talk to each other so they can figure out what's going on
> and give advice to the customer. Right now I see forum posts all the
> time with people frantically kicking all the things to try to figure out
> what's going on. There is no indication to them if the connectivity is
> bad because the problem is in their home network, on the access line,
> ISP core network, or further out from the Internet. People just don't
> have the tools to help them understand what's going on. The only thing
> they can say is "my Internet is slow", which of course says nothing what
> the problem really is. Current devices can't even tell them if DNS
> lookups are slow, if TCP establishment is slow, if TCP transfer rate is
> low because of packet loss, because of high delay, because of something
> else. This information just isn't available to the end user, and it's
> sad state of affairs.
>

Well that's the part that isn't easy to do. Particularly since
different problems can have identical symptoms. They may have slight
packet loss that doesn't impact anything other than DNS or other UDP
and makes sites far away very slow while sites within a few hops are
not affected.

> The IETF, vendors and ISPs are all quite siloed so I don't know where we
> would start to actually improve this. I tried talking to the TCP people
> at the IETF and had no takers. I tried talking to the IPPM people, but
> they just want to measure with test traffic. I don't know who to talk to
> next.
>

I think an area that can be improved greatly in CPEs is enhanced signal
reporting. You look at a typical cable modem CPE and it might show
signal to noise ratios on the cable but there's nothing in the interface
showing if the numbers are good or bad. Even putting a bar in there
that shows a continuum of red to green with the signal somewhere on that
would be helpful - as the customer can tell the tech support person
"My WAN signal levels are all showing red" and the frontline support
person can't then argue that's normal. After all, all WAN connectivity
does run on lower level something.

Ted

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

On 20.9.2016 9:00, erik.taraldsen@telenor.com wrote:
> We also hoped that UPnP/PCP would be activly used in IPv6, punching firewall holes as needed. But that seems to not get any traction.

any good documents on this issue (upnp and IPv6) ?

> > We also hoped that UPnP/PCP would be activly used in IPv6, punching firewall holes as needed.
> > But that seems to not get any traction.
>
> any good documents on this issue (upnp and IPv6) ?

UPnP and IPv6:
https://openconnectivity.org/upnp/specifications/internet-gateway-device-igd-v-2-0
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf
Chapter 2.3.5, WANIPv6FirewallControl:1

If you ment documentation on (lack of) traction I just have the answers in the RFQ's we have sent + talks we have with vendors at such events as BBFW (https://tmt.knect365.com/bbwf/). The RFQ's are under NDA so I can't disclose who or what capabilitys they offer. But in general, very little UPnP + IPv6.

And just to trow this conversation futher of, anybody else here coming to BBWF this year?

-Erik

On 29/09/2016, 10:26, "ipv6-ops-bounces+ragnar.anfinsen=altibox.no@lists.cluenet.de on behalf of erik.taraldsen@telenor.com" <ipv6-ops-bounces+ragnar.anfinsen=altibox.no@lists.cluenet.de on behalf of erik.taraldsen@telenor.com> wrote:

>And just to trow this conversation futher of, anybody else here coming to BBWF this year?

I’ll be there... Beers?

/Ragnar

>>And just to trow this conversation futher of, anybody else here coming to BBWF this year?
>
> I’ll be there... Beers?

Good idea. Any non-Norwegians who would like to join? :)

-E

CU at BBWF ;-) We are building CPE with IPv6 on board.

https://tmt.knect365.com/bbwf/sponsors/avm

Eric





Von: <erik.taraldsen@telenor.com>
An: <Ragnar.Anfinsen@altibox.no>
Kopie: ipv6-ops@lists.cluenet.de
Datum: 29-09-2016 11:27
Betreff: SV: SV: SV: CPE Residential IPv6 Security Poll
Gesendet von: ipv6-ops-bounces+e.vanuden=avm.de@lists.cluenet.de



>>And just to trow this conversation futher of, anybody else here coming
to BBWF this year?
>
> I’ll be there... Beers?

Good idea. Any non-Norwegians who would like to join? :)

-E

Am 29.09.2016 um 13:50 schrieb e.vanuden@avm.de:
> CU at BBWF ;-) We are building CPE with IPv6 on board.
>
> https://tmt.knect365.com/bbwf/sponsors/avm
>
> Eric

Without IPv6-support for vpn, without configurable firewall for
dhcpv6-pd, without the ability to disable IPv4-myfritz-DNS-entries.
Some IPv6-menus still hidden, only in expert view or far far away from
the users focus.

AVM is good, but not perfect.


Regards,
Thomas





--

There’s no place like ::1

Thomas Schäfer (Systemverwaltung)
Ludwig-Maximilians-Universität
Centrum für Informations- und Sprachverarbeitung
Oettingenstraße 67 Raum C109
80538 München ☎ +49/89/2180-9706 ℻ +49/89/2180-9701

On 29.09.2016 14:28, Thomas Schäfer wrote:
> Am 29.09.2016 um 13:50 schrieb e.vanuden@avm.de:
>> CU at BBWF ;-) We are building CPE with IPv6 on board.
>>
>> https://tmt.knect365.com/bbwf/sponsors/avm
>>
>> Eric
>
> Without IPv6-support for vpn, without configurable firewall for
> dhcpv6-pd, without the ability to disable IPv4-myfritz-DNS-entries.
... without static routes for IPv6 and, to come back to the original
topic: Without the possibility to turn of the IPv6 firewall...

> AVM is good, but not perfect.
Ack! And I like the way how the IPv6 firewall is configurable, but a
(maybe somehow hidden) knob to turn it completely off, or even set it to
a relaxed security like the Swisscom way, would be great.

BR
Holger

On Thu, Sep 29, 2016 at 01:50:07PM +0200, e.vanuden@avm.de wrote:
> CU at BBWF ;-) We are building CPE with IPv6 on board.

Which still can't even do static IPv6 routes or open firewall for
adresses in prefixes not directly connected.

Example: getting a /48 from upstream, either statically routing or
PD'ing this to another inside router. No way to disable firewalling for
those.

Since AVM did close the shell access to the FB, you cannot even manually
add the static routes. So FB with current OS is basically unusable for
anything but directly connected networks (main/guest) in IPv6. I'm
looking for a replacement for my 7390 as this problem doesn't allow me
to upgrade firmware anymore (as I would lose telnet access and thus IPv6
in my home networks).

Nevertheless, welcome to the list. :-)

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0