Subject: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 10 Nov 2013 11:00:10 -0800 (PST)

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security.  Please read it now. If you find nits
(spelling errors, minor suggested wording changes, etc), comment to the
authors; if you find greater issues, such as disagreeing with a
statement or finding additional issues that need to be addressed,
please post your comments to the list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

---

From: Tarko Tikan <[email-masked]>
Date: Tue, 12 Nov 2013 19:44:19 +0200

hey,

> believe it to be of operational utility, that is also an important

+1 from me (as an operator) for the concept. This is similar to what I 
plan to deploy but with one exception - we will not do this in the CPE, 
we will do it in the edge routers via subscriber management instead.

This way we can configure it centrally and very easily push new policy 
for certain subscriber when one wants to have "permit any" inbound. For 
us this also follows IPv4 operating model (which might not always be the 
best case but feels like a best case for us).

I'm _not_ saying doing this in the CPE is wrong, this is very typical 
for the cable operators for example - configure everything via modem 
config files delivered on boot. Or for operators who have no subscriber 
awareness in the edge routers. YMMV.

-- 
tarko,
elion.ee

---

From: Marc Lampo <[email-masked]>
Date: Tue, 12 Nov 2013 20:39:36 +0100

sorry for being late in the process, but I do have some remarks on the
content of this draft :

Personally I don't like the 3.1 point 3: Rule openness
Open by default, except for a list of configurable/updatable protocol+port
numbers.

What I would like, in an IPv6 capable home gateway is that I can define
what port(s)
are allowed to which internal device - either manually or some pcp.
So, from RFC 6092, REC-48 (define what is allowed) + REC-33 (drop
everything else)

In my opinion there is nothing wrong with RFC 6092.
Why not implement it ?
Why an (informational) RFC on an implementation that does not, and states
no explicit reason for not doing it.

It is unclear if the list of threats, section 2, is in relationship with
what will be achieved by this implementation.
Take the last of the list, that refers to : "covert channel"
(regardless if a trojanised host, in or out of a botnet is involved)
In the book IPv6 & Security, of which you, Erik, are coauthor, the term
"covert channel" is linked to
the destinations options extension header.
But this draft does not elaborate further on covert channel, nor does it
state that implementation blocks covert channels.
I think it is misleading the reader to refer to the threat and not propose
something against it.
(at least, I cannot interpret the draft/implementation as : drop any IPv6
packet with a destination options extension header)

Although I cannot support a default open policy, and (only just) heard the
Berlin audio with the remarks on the port list,
but SUN Remote Procedure Call is both UDP and TCP port 111 (for section 3.2)

Consequently, in my opinion the "Security" section of the draft is too
"soft".
Rather then :
- unauthorized access blocked because vulnerable ports are blocked
why not
(from http://tools.ietf.org/html/draft-ietf-mext-firewall-vendor-05)

   One of the main goals of any firewall is to prevent unsolicited
   traffic from entering the network.  The proposed solution allows such
   traffic into the network, albeit with a number of restrictions.

(that draft seems expired anyway, lucky us)

Kind regards,

Marc

On Sun, Nov 10, 2013 at 8:00 PM, Fred Baker <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 12 Nov 2013 21:54:16 +0000

This is a comment as a participant, not as a chair.

I find myself scratching my head with this, and found myself scratching my head with what became RFC 6092.

My first premise in both cases is that a firewall primarily mitigates attacks on the bandwidth of a network and an aggregated network. An attack that actually hits a host or application will have to be defended against by the host/application or a security service provided by some other device in the network; firewall rules provide a form of defense in depth, but no more. I compare a firewall to the human skin. The skin is, itself, hardly necessary for the "health security" of the body, as the other systems of the body could be active and mitigate attacks on the body. However, it makes active use of those capabilities less of a requirement by preventing certain classes of attacks.

My second premise is that any communication attempt directed to a network, or to a application in a network, that doesn't have a application in the network that willingly communicates with it is an attack.

Now, we have tools - PCP, UPnP - that enable an application to inform the network of its approving presence. If I want someone to be able to connect to a given device using IPsec, when the device comes up, it can inform the network of a n-tuple {application address, IPsec protocol ID, <any>}, and "poke a hole" in a firewall regardless of the description of the firewall. The administration can also log such requests and apply its own policy on whether it honors them. If I want them to initiate SMTP or https connections to a given system, it can similarly announce itself as {address, TCP, port, any, any}, and allow incoming SMTP connections to it.

So regardless of the firewall type, we have tools to enable an application in the network to make itself available to peers "outside". And of course, as suggested in zone-based defenses and in RFC 6092, when a application initiates a connection outside, by implication the firewall can open a "hole" for the return traffic.

So the only protocols, or peers using protocols, under discussion are those that have no application that is willing to have sessions initiated to it from the outside of the network.

RFC 6092 permits IPsec packets as a blanket rule. That facilitates two attacks. First, there is a form of network scanning enabled; a application outside the network can initiate IKE connections to addresses it thinks might exist in the network (observing, for example, email envelope information to find such addresses); if it gets a reply, something is using the address. Second, it can busy out the verification/decrypt unit in a application simply by sending it IPsec traffic that does not have a proper key. That can DOS the application's CPU resources or its communication resources. Now, if a application wants to communicate in that way and recognizes the vulnerability, it can open that hole. But if a application doesn't want to communicate that way (for example, it implements IPsec but the applications it uses have no keys to validate data with), what is the argument for leaving the vulnerability open?

draft-ietf-v6ops-balanced-ipv6-security implements a similar, and much wider, vulnerability. I might well have an http server in my network, but that doesn't imply that all hosts in my network are http servers. Even if many of the hosts in my network are http servers, that doesn't imply that my policy enables access to them from all possible clients. My http server can open a hole for itself, and can be armored to defend it against the many attacks that plague that protocol. My telephones (Cisco 9971 and iPhone 5) are, or can be, http servers as well. Does that mean that my call configuration and history should be available to anyone who wonders about it? Is the presence of one server a reason to expose the many hosts in my network that only operate as clients to HTTP initiated from the outside?

http://www.economist.com/news/science-and-technology/21589383-stung-revelations-ubiquitous-surveillance-and-compromised-software

From my perspective, I think I would prefer that the firewall - if implemented - blocked everything, and applications within the network advised the firewall(s) of traffic that they are willing to receive. If a potential session has no willing counterpart within my network, I don't see the argument for letting the first packet in.

---

From: Guillaume Leclanche <[email-masked]>
Date: Tue, 12 Nov 2013 17:44:51 -0500

2013/11/12 Fred Baker (fred) <[email-masked]>

> From my perspective, I think I would prefer that the firewall - if
> implemented - blocked everything, and applications within the network
> advised the firewall(s) of traffic that they are willing to receive. If a
> potential session has no willing counterpart within my network, I don't see
> the argument for letting the first packet in.

I think this calls for the introduction of a new draft that is not existing
yet (or, is it ?). I like the proposal, it's simply another preset of
settings for a CPE firewall (which, in the end, should always be
configurable by the end user). The document could describe how the CPE
should behave with this security setting when interacting with the various

That way the documents "portfolio" would cover three possible default
settings, that could be implemented as presets on CPEs: RFC9092,
draft-balanced-security, draft-(strict?)-security. They are complementary.

Guillaume

---

From: Guillaume Leclanche <[email-masked]>
Date: Tue, 12 Nov 2013 17:47:16 -0500

> draft-balanced-security, draft-(strict?)-security. They are complementary.

obviously 6092 not 9092.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Nov 2013 03:34:17 +0100 (CET)

On Tue, 12 Nov 2013, Fred Baker (fred) wrote:

> advised the firewall(s) of traffic that they are willing to receive. If 
> a potential session has no willing counterpart within my network, I 
> don't see the argument for letting the first packet in.

My biggest problem with this resoning, is that I am not aware of any 
firewall poking mechanism actively being in use for IPv6. This means that 
if we have a firewall with default-deny for incoming connections, then 
either hosts need an Internet based machine to coordinate a STUN type of 
behaviour to get the firewall to accept packets for sessions, or they need 
to implement a firewall poking mechanism that as far as I know, neither 
todays firewalls/CPEs nor hosts actually has.

So today, implementing default-deny would mean a lot of the benefit of 
IPv6 wouldn't be seen immediately but would takes many years to realise. 
Right?

Or am I mistaken and uPNP for IPv6 actually functional today? PCP I have 
never seen in home devices.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "cb.list6" <[email-masked]>
Date: Tue, 12 Nov 2013 18:53:37 -0800

That's my view too

I would rather restore e2e than deploy pcp. Or firewall  related ALGs.

At the end of the day, this draft is an excellent start towards restoring
e2e in a pragmatic and prudent way.  It is deployed and successful and is
thusly a reference for us all.  I fully support it as written since it will
help p2p technologies like webrtc and Microsoft Xbox One, as presented at
ietf88.

CB

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Nov 2013 03:05:07 +0000

On Nov 12, 2013, at 9:34 PM, Mikael Abrahamsson <[email-masked]> wrote:
> Or am I mistaken and uPNP for IPv6 actually functional today? PCP I have never seen in home devices.

PCP is present in Apple's Time Capsule gateways.   It would be nice to see an implementation in OpenWRT, but you're right that none exists as of now.   There is a uPNP/NAT-PMP implementation for OpenWRT, but I don't know if it supports IPv6.

---

From: "cb.list6" <[email-masked]>
Date: Tue, 12 Nov 2013 20:54:38 -0800

Hi Fred,

> I find myself scratching my head with this, and found myself scratching my head with what became RFC 6092.

rightfully so.

> My first premise in both cases is that a firewall primarily mitigates attacks on the bandwidth of a network and an aggregated network. An attack that actually hits a host or application will have t…

I believe the core of the issue is stateful firewalling, at least the
core of the issue for me is stateful firewalls -- so when i say
firewall please assume that is what i mean.

Networks exist without firewalls, humans do not exist without skin.

> My second premise is that any communication attempt directed to a network, or to a application in a network, that doesn't have a application in the network that willingly communicates with it is an…

I disagree.  If you want to call me with WebRTC or Xbox One and i am
not willing to talk right now, that is not an attack.  I prefer the
term attack to be scoped to only that with malicious intent.

> Now, we have tools - PCP, UPnP - that enable an application to inform the network of its approving presence. If I want someone to be able to connect to a given device using IPsec, when the device c…

PCP and UPnP may be tools to inform the network of something, but if a
tree falls in the woods, does it make noise?  My point is that i have
no plans to support either and if someone requires PCP or UPnP i will
suggest they use IPv6.  IPv6 does not need these hacks that IPv4 did.
I believe these tools are in fact a huge vector for attack, and i
believe that is supported by common knowledge that attacks have
shifted from networks to applications.  And, UPnP and PCP are
applications.  Thus, UPnP and PCP will become the achilles heel of
networks, especially if we come to rely upon them

Here is one example of UPnP issues
https://community.rapid7.com/community/infosec/blog/2013/01/29/security-flaws-in-universal-plug-and-play-unplug-dont-play

And, here is an example of why your "router/firewall" should not be
given keys to the kingdom,
http://seclists.org/fulldisclosure/2013/Nov/76

Or this nakedsecurity.sophos.com/2012/10/01/hacked-routers-brazidnsl-vb2012/

I think we know pretty well that home routers are some of the worst
maintained code around.  Witness the buffer bloat debacle and the
challenge home router CPE is providing for many residential IPv6
deployment.  And, security issue after security issue, like this
d-link backdoor

http://www.kb.cert.org/vuls/id/248083

I think the conversation would be different if the home gateways /
routers /  firewalls had any credibility as secure devices, but they
don't.  Moderm mobile and PC operating systems are much much better.

> So regardless of the firewall type, we have tools to enable an application in the network to make itself available to peers "outside". And of course, as suggested in zone-based defenses and in RFC…

An application, including malware may configure your firewall or your
provider's CGN.  See the above security issues of CPE.

> So the only protocols, or peers using protocols, under discussion are those that have no application that is willing to have sessions initiated to it from the outside of the network.

Which would exclude anyone using from p2p gaming, WebRTC, ...

> RFC 6092 permits IPsec packets as a blanket rule. That facilitates two attacks. First, there is a form of network scanning enabled; a application outside the network can initiate IKE connections to…

Your premise is that a stateful firewall disallows inbound connections
to protect bandwidth on the LAN

Yet, RFC 6092 says we must allows anyone to send us IPsec.

Which simply means attackers focus their tools on generating high
volumes of IPsec packets and can attack the LAN with a flood of IPsec.

So, RFC6092 did not solve the bandwidth attack, yet it encumbered the
applications to have to work-around  stateful packet filtering with
ALG / PCP / UPnP ...

This is a lose / lose.

> draft-ietf-v6ops-balanced-ipv6-security implements a similar, and much wider, vulnerability. I might well have an http server in my network, but that doesn't imply that all hosts in my network are…

1.  Your HTP server can open a firewall hole for itself for inbound
connections?  Please explain this implementation.

2.  Your HTTP server iPhone is serving your call records to any client
that can make a connection?  And you think a firewall is the solution
to that ?  :)

3.  If you believe the internet should only be HTTP clients, this
stateful filtering model is for you.  On the other hand, the IETF has
many efforts to take the internet to a more secure, more distributed
p2p model, less "cloud" dependent.

> From my perspective, I think I would prefer that the firewall - if implemented - blocked everything, and applications within the network advised the firewall(s) of traffic that they are willing to…

I would rather have secure hosts, smart endpoints, and simple networks.

My view of the world

1. Prior to 1999 network security was not taken very seriously

2.  In 2000-2003, NIMDA, Code Red, SQL Slammer were a big deal and we
all installed firewalls.  These attacks were real bad.

3.  2005 -> future:  hosts come with firewalls on by default,  the
network stack is not a major attack surface, security is concern for
all parties.  On the other hand, malware has focused on application
and user.

4.  There is a security industry that still wants to sell you middle
boxes, despite the fact they add little to no value.  In fact, these
middle boxes are themselves the weakest / fragile / stateful link the
in chain.

CB

---

From: Tore Anderson <[email-masked]>
Date: Wed, 13 Nov 2013 09:06:42 +0100

* Fred Baker (fred)

> My first premise in both cases is that a firewall primarily mitigates
> attacks on the bandwidth of a network and an aggregated network.

For this to actually be the case, the firewall's WAN link must have a
higher bandwidth than the LAN it protects. I'd say this is rather
uncommon in residential broadband these days, so the even if the CPE's
firewall drops absolutely *everything*, a bandwidth attack would still
succeed.

Tore

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Nov 2013 09:30:42 +0100 (CET)

On Tue, 12 Nov 2013, Fred Baker (fred) wrote:

> My second premise is that any communication attempt directed to a 
> network, or to a application in a network, that doesn't have a 
> application in the network that willingly communicates with it is an 
> attack.

If it doesn't want to communicate, then it gives connection refused.

For me, a firewall is a way to have a policy that disallows connections to 
"dumb" services "inside" that can't protect itself. Basically, the 
firewall means that instead of making the home part of the Internet, it 
tries to limit its participation.

The classic unix model is that services below 1024 are privileged ports, 
and there lives most of the "sensitive" services. Userspace processes live 
in 1024 and above.

I believe I voiced opinion that I was fine with disallowing unsolicited 
connections from the outside to inside ports below 1024. This would mean 
most home services would not be accessible from the outside, but at least 
most of the peer-to-peer communication applications would work without 
restrictions since these live in the high ports.

The draft being discussed, balanced-security tries to identify weak 
services. I am fine with this approach as well, since it means the user 
doesn't have to do administration of for instance ssh services, but still 
blocks communication for the more common weak services. Having all 
incoming connections blocked would be a mistake, in my opinion.

I therefore support the WGLC of the above draft.

---

From: Tarko Tikan <[email-masked]>
Date: Wed, 13 Nov 2013 10:42:55 +0200

hey,

>  From my perspective, I think I would prefer that the firewall - if implemented - blocked everything, and applications within the network advised the firewall(s) of traffic that they are willing to…

That would be preferred but as already discussed, there are no suitable 
protocols (and implementations) for deployment today. And recommending 
to block all inbound sessions by default is not good idea with IPv6 
end2end mentality.

To improve on the idea - I don't see why application should signal to 
CPE, firewalling in CPE is useless against ddos attacks. I'd prefer 
application to signal to edge routers and have firewall there, this way 
to-be-denied packets never make it to CPE and will not congest AN uplinks.

-- 
tarko

---

From: Marc Lampo <[email-masked]>
Date: Wed, 13 Nov 2013 10:30:22 +0100

Hello,

but is "IPv6 end2end mentality" a good idea, from the security point of
view ?  I don't think so.

Kind regards,

On Wed, Nov 13, 2013 at 9:42 AM, Tarko Tikan <[email-masked]> wrote:

> protocols (and implementations) for deployment today. And recommending to
> block all inbound sessions by default is not good idea with IPv6 end2end
> mentality.
>
> To improve on the idea - I don't see why application should signal to CPE,
> firewalling in CPE is useless against ddos attacks. I'd prefer application
> to signal to edge routers and have firewall there, this way to-be-denied
> packets never make it to CPE and will not congest AN uplinks.
>
> --
> tarko
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Nov 2013 10:33:15 +0100 (CET)

> but is "IPv6 end2end mentality" a good idea, from the security point of 

Making things not work is very secure, but not very useful.

What is your proposal for tradeoff between these two factors?

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 13 Nov 2013 02:25:49 -0800 (PST)

>________________________________
> From: Marc Lampo <[email-masked]>
>To: Tarko Tikan <[email-masked]> 
>Cc: [email-masked] 
>Sent: Wednesday, 13 November 2013 8:30 PM
>Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC
> 
>
>
>Hello,
>
>but is "IPv6 end2end mentality" a good idea, from the security point of view ?  I don't think so.
>

I don't think that mentality will survive crypto and multipathing (e.g. MPTCP).

The mobility of our hosts (such as smartphones/tablets/laptops) and therefore the operating systems they run has caused them to become far more self reliant (starting probably around October 2004, the release of Windows XP SP2), because they can't trust the network to do that job for them. This is a consequence of them being able to move between many different networks, with various levels of "protection". They (or rather, their vendors) assume the worst case of a public IP address on an unfettered Internet connection, and prepare the hosts for that by default.

Multipathing is going to make that worse, because one path may be "heavily" protected (e.g., corporate network), while the other path may have no protection at all (e.g., carrier network, or different Wifi network). MPTCP or similar will try to use both at once, and therefore the host will have to encrypt the traffic to be sure of its integrity and protection.

I think this draft is just to simplistic. It seems to be making the assumption that hosts aren't protecting themselves at all, and that TCP or UDP ports are absolute indicators of the security or not of a protocol. 

For example, SSH is blocked, yet SNMP isn't. I'd argue the other way around is correct, except that SNMPv3 is secure, yet it uses the same UDP ports as SNMPv1 and v2, which aren't adequately secure. Asserting that SSH should be blocked is really asserting that all people who use single-factor SSH authentication have picked bad passwords, and that nobody is using two factor SSH authentication. I think that is a way too coarse and sweeping generalisation.

For the same reasons, I don't think you can use greater than or less than 1024 as an absolute security indicator. There are a number protocols which use ports below 1024 that have encryption or authentication as options or standard features.

If CPE should be doing anything, I think it should only be providing assistance that the hosts might find useful (the scenario Fred described), rather than being viewed as the primary and only security device protecting the hosts. If the CPE gets in the way of what the hosts want to do, then the hosts will just use the IPv4 NAT ("firewall") traversal techniques to traverse IPv6 firewalls that get in their way, or will just wrap everything inside IPsec, completely nullifying any protection the CPE might try to provide, and the associated time and effort spent developing that "protection". I think CPE providing tools that would be of assistance might be useful to hosts, but trying to make absolute judgements on-behalf of the hosts without knowing what the hosts actually want and need would be harmful.

Regards,
Mark.

>> From my perspective, I think I would prefer that the firewall - if implemented - blocked everything, and applications within the network advised the firewall(s) of traffic that they are willing to…
That would be preferred but as already discussed, there are no suitable protocols (and implementations) for deployment today. And recommending to block all inbound sessions by default is not good idea with IPv6 end2end mentality.
>>
>>To improve on the idea - I don't see why application should signal to CPE, firewalling in CPE is useless against ddos attacks. I'd prefer application to signal to edge routers and have firewall there, this way to-be-denied packets never make it to CPE and will not congest AN uplinks.
>>
>>-- 
>>tarko
>>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Nov 2013 15:29:52 +0000

On Nov 13, 2013, at 3:42 AM, Tarko Tikan <[email-masked]> wrote:
> I'd prefer application to signal to edge routers and have firewall there, this way to-be-denied packets never make it to CPE and will not congest AN uplinks.

You could definitely do this with PCP, but do you really want to encourage the installation of firewalls in this part of the network?   I suspect the law of unintended consequences is worth paying attention to here.

---

From: Tarko Tikan <[email-masked]>
Date: Wed, 13 Nov 2013 17:58:39 +0200

hey,

> You could definitely do this with PCP, but do you really want to encourage the installation of firewalls in this part of the network?   I suspect the law of unintended consequences is worth paying…

There are pros and cons like always. Considering people put subscriber 
awareness, CGN (stateful) etc. into PEs, adding firewalls is not that 
big of a deal. Scale is an issue but current hardware can already do 
tens of gigabits worth of stateful firewalling.

Then again it adds cost and raises complexity (lower MTBF) and CPEs are 
there and paid for.

-- 
tarko

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 13 Nov 2013 16:46:38 +0000

> To improve on the idea - I don't see why application should signal to CPE, firewalling in CPE is useless against ddos attacks. I'd prefer application to signal to edge routers and have firewall the…

The action of the application would  be the same, right? If the user has a managed service, one can easily imagine the upstream firewall/router doing this. That simply says where the PCP traffic would go to.

The "IPv6 end2end mentality", I would argue, doesn't come into play here. The phrase "end to end" implies having multiple endpoints. If there is no application in the network prepared to be the receiving end, the sending end can do whatever it likes - there is nobody to talk with. And from a policy perspective, even if there is someone that *could* talk (the HTTP server on my phone, designed for management use), that doesn't imply that I want it to. I'm fine with saying there will be no impedance of traffic that is useful and fits policy. As far as I know, firewalls aren't supposed to block that anyway.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Nov 2013 18:19:17 +0000

On Nov 13, 2013, at 10:58 AM, Tarko Tikan <[email-masked]> wrote:
> There are pros and cons like always. Considering people put subscriber awareness, CGN (stateful) etc. into PEs, adding firewalls is not that big of a deal. Scale is an issue but current hardware can already do tens of gigabits worth of stateful firewalling.

You completely missed my point.   Do you really want your ISP filtering your data stream?

---

From: Marc Lampo <[email-masked]>
Date: Wed, 13 Nov 2013 20:47:05 +0100

I as well would prefer that unsolicited traffic from the Internet is
stopped at the border of the network - like RFC 6092 recommends (though I
don't see a recommendation for incoming UDP traffic ?)

If a device in the network desires to communicate with the outside world,
it is probably/hopefully after an act of configuration (of its owner) on
that device.  That outgoing traffic could be the trigger to allow the rest
of the communication.
If, in some years, fridges have IPv6 connectivity, perhaps they might send
an inventory or shopping list to your mobile device (outgoing traffic)
But probably/hopefully that will only happen after it was configured with
some destination and authentication data so that the info arrives on your
mobile and does indeed come from your fridge.
But the fact that the fridge does have connectivity does not imply I would
allow my favorite shop to come and look, or some marketing firm, or the
fridge of a neighbor in search for eggs (s)he forgot ...

So, by default allow the first packet towards ports "considered harmless" ?

As Fred already pointed out, the listener on TCP port 80 might not be a
webserver;
and why would any port (lower or higher than 1024)  be harmless ?
After all, malware could chose any free port.
The number 1024 is only there because, on UNIX, it requires super user
privileges to bind to low ports.

Hence, in my opinion, the security (and privacy) of IPv6 users is best
served by keeping unsolicited traffic out.

Kind regards,

---

From: Tarko Tikan <[email-masked]>
Date: Wed, 13 Nov 2013 23:25:10 +0200

hey,

> You completely missed my point.   Do you really want your ISP filtering your data stream?

No I didn't.

As a provider I worry about DOS hitting my ANs and worms/viruses 
spreading in my network.

As a customer I worry about getting hacked (which didn't happen with v4 
NAT - not a strong argument ofc as customers mostly get infected via 
drive-by malware these days). I also want to manage it myself to some 
level, minimally just enable/disable.

We currently provide stateless filter for our broadband customers. 
Filtering is done in edge routers and not CPE. Unfortunately customers 
can't customize the rules because it just wouldn't scale today (would 
need to create ACL for every customer).

-- 
tarko

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Nov 2013 06:42:19 +0100 (CET)

> served by keeping unsolicited traffic out.

You and me have a very different opinion what unsolicited is. If the host 
accepts connections on a port, then it has by definition accepted to 
handle the connection. There is no reason access control can't be handled 
on the host.

I would rather see a mechanism that the host can use to say "please 
protect me, I'm helpless" and then the gateways will filter traffic to the 
device (ie if the host says nothing then default policy is open) than what 
you're proposing which is "default close".

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 14 Nov 2013 06:07:28 +0000

On Nov 13, 2013, at 9:42 PM, Mikael Abrahamsson <[email-masked]>
 wrote:

>> Hence, in my opinion, the security (and privacy) of IPv6 users is best served by keeping unsolicited traffic out.
> 
> You and me have a very different opinion what unsolicited is. If the host accepts connections on a port, then it has by definition accepted to handle the connection. There is no reason access control can't be handled on the host.

The question here, if I understand Marc, is who sent the first packet. If the TCP SYN (or counterpart in whatever protocol) was sent by the host within the domain, an RFC 6092 firewall will permit traffic in response. If the TCP SYN was sent by the peer to that host, an RFC 6092 firewall will prevent that and everything following. Having the host say to the firewall that it is willing to accept unsolicited communications is quite a bit different than initiating those communications.

> I would rather see a mechanism that the host can use to say "please protect me, I'm helpless" and then the gateways will filter traffic to the device (ie if the host says nothing then default policy is open) than what you're proposing which is "default close".

What about a host that is so helpless that it doesn't say so?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Nov 2013 17:14:54 +1100

In message <[email-masked]>, "Fred Baker (fred)
" writes:
> > You and me have a very different opinion what unsolicited is. If the
> host accepts connections on a port, then it has by definition accepted to
> The question here, if I understand Marc, is who sent the first packet. If
> the TCP SYN (or counterpart in whatever protocol) was sent by the host
> within the domain, an RFC 6092 firewall will permit traffic in response.
> If the TCP SYN was sent by the peer to that host, an RFC 6092 firewall
> will prevent that and everything following. Having the host say to the
> firewall that it is willing to accept unsolicited communications is quite
> a bit different than initiating those communications.
>
> protect me, I'm helpless" and then the gateways will filter traffic to
> the device (ie if the host says nothing then default policy is open) than
> what you're proposing which is "default close".
>

Then it should be put in the bin.  Equipment should expect to be
exposed to the Internet as a whole.  It's not like this is a new
concept.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Nov 2013 07:56:15 +0100 (CET)

On Thu, 14 Nov 2013, Fred Baker (fred) wrote:

> The question here, if I understand Marc, is who sent the first packet. 
> If the TCP SYN (or counterpart in whatever protocol) was sent by the 
> host within the domain, an RFC 6092 firewall will permit traffic in 
> response. If the TCP SYN was sent by the peer to that host, an RFC 6092 
> firewall will prevent that and everything following. Having the host say 
> to the firewall that it is willing to accept unsolicited communications 
> is quite a bit different than initiating those communications.

Absolutely.

>> the device (ie if the host says nothing then default policy is open) 
>> than what you're proposing which is "default close".
>

I guess this is what it all boils down to, world view. I want the home to 
be full part of the Internet as default, whereas others seem to want a 
filtered view.

Most of the devices today can handle themselves having unfiltered access 
to the Internet. Phones and computers are regularily exposed to the 
Internet and have sane defaults to handle this. I have plenty of computers 
and other devices on GUA IPv4 and IPV6 addresses and they have been fine.

Most infections happen because of pulled content, not pushed, so I don't 
really see the big advantage of disallowing incoming connections. What I 
*would* like to hear from is more application designers, and their view. 
Are they ok with having incoming connections blocked? What do the vendors 
of Facetime, Back-to-my-mac, Viber, Skype etc say about this? Ekiga? Cisco 
Jabber Video? Otoh the vendors of these have infrastructure on the 
Internet to help them, which others do not.

So, Torrent clients? Microsoft One? Microsoft remote desktop stuff? VNC? 
These are the applications we might be killing with this default close 
policy that is being proposed.

---

From: Marc Lampo <[email-masked]>
Date: Thu, 14 Nov 2013 08:58:22 +0100

by "unsolicited" I understand : the initiative to start the communication
is on the Internet side.  So, if RFC6092 is implemented, that kind of
traffic is not allowed.  (Sorry for the confusion on the word)

On Thu, Nov 14, 2013 at 7:07 AM, Fred Baker (fred) <[email-masked]> wrote:

> within the domain, an RFC 6092 firewall will permit traffic in response. If
> the TCP SYN was sent by the peer to that host, an RFC 6092 firewall will
> prevent that and everything following. Having the host say to the firewall
> that it is willing to accept unsolicited communications is quite a bit
> different than initiating those communications.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Nov 2013 09:56:11 +0100 (CET)

On Thu, 14 Nov 2013, Marc Lampo wrote:

> by "unsolicited" I understand : the initiative to start the 
> communication is on the Internet side.  So, if RFC6092 is implemented, 
> that kind of traffic is not allowed.  (Sorry for the confusion on the 
> word)

There was no confusion on my side, I understood you exactly this way.

It's just that if the device signals to the firewall that it wants to 
allow certain ports to be allowed, any SYN packet from the outside is 
still unsolicited. It just happens that you've moved the access control 
from the host IP stack to an intermediate device that needs to apply the 
same policy as the host could have done.

By accepting SYN packets on port 80, you're soliciting connections. If you 
don't want to accept SYN port 80 from everywhere, then don't accept it. 
There is little added benefit in having a signaling mechanism to an 
intermediate device (firewall) to do the same functionality.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 13 Nov 2013 17:00:52 +0100

Hi Mikael,

Op 13 nov. 2013, om 09:30 heeft Mikael Abrahamsson <[email-masked]> het volgende geschreven:

> For me, a firewall is a way to have a policy that disallows connections to "dumb" services "inside" that can't protect itself. Basically, the firewall means that instead of making the home part of the Internet, it tries to limit its participation.
> 
> The classic unix model is that services below 1024 are privileged ports, and there lives most of the "sensitive" services. Userspace processes live in 1024 and above.
> 
> I believe I voiced opinion that I was fine with disallowing unsolicited connections from the outside to inside ports below 1024. This would mean most home services would not be accessible from the outside, but at least most of the peer-to-peer communication applications would work without restrictions since these live in the high ports.
> 
> The draft being discussed, balanced-security tries to identify weak services. I am fine with this approach as well, since it means the user doesn't have to do administration of for instance ssh services, but still blocks communication for the more common weak services. Having all incoming connections blocked would be a mistake, in my opinion.
> 

Well said. I support the WGLC of the above draft as well.

Cheers,
Sander

---

From: Marc Lampo <[email-masked]>
Date: Thu, 14 Nov 2013 11:50:06 +0100

I realise now that "unsolicited" is a word allowing multiple
interpretations (but also used in RFC 6092).  But we seem to have got it
right.

Anyway, the fact that some service, on an internal device, is willing to
accept connections on port XYZ,
does not, in my opinion, imply that those connections may also come from
the outside Internet.
Back to the example with the refrigerator :
suppose it has a service (port XYZ) that allows it to be queried for its
contents.
Probably great when one is at home, but does this mean accessible from
anywhere on the Internet ?

In my opinion : not before the owner has explicitly instructed his CPE to
allow incoming connections (RFC 6092, REC-48).

Kind regards,

On Thu, Nov 14, 2013 at 9:56 AM, Mikael Abrahamsson <[email-masked]>wrote:

> allow certain ports to be allowed, any SYN packet from the outside is still
> unsolicited. It just happens that you've moved the access control from the
> host IP stack to an intermediate device that needs to apply the same policy
> as the host could have done.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Nov 2013 11:55:13 +0100 (CET)

On Thu, 14 Nov 2013, Marc Lampo wrote:

> In my opinion : not before the owner has explicitly instructed his CPE 
> to allow incoming connections (RFC 6092, REC-48).

I guess we'll just have to disagree then.

I believe the owner should put their devices on a DMZ if they want this 
behaviour, not that this behaviour should be default.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Nov 2013 08:13:49 +1300

On 14/11/2013 19:56, Mikael Abrahamsson wrote:
...
> Internet and have sane defaults to handle this. 

That's a vital point. Mobile devices, including laptops, are potentially
exposed to raw Internet, so relying on a separate firewall is totally
unsafe. That's not to say that firewalls are pointless - it's helpful if
unwanted traffic is dropped at the perimeter - but if your device isn't
intrinsically protected, all hope is lost as soon as you step outside
the building. In these days of BYOD, unprotected devices will end up
infected and will later infect the corporate network, so even screwed-down
desktop devices need intrinsic protection.

That said, the *informational* draft in question is useful as an example
of a possible deployment scenario.

    Brian

---

From: joel jaeggli <[email-masked]>
Date: Thu, 14 Nov 2013 11:22:05 -0800

> desktop devices need intrinsic protection.

It is reasonable to suppose that most devices should not assume that a
home network is anymore trustworthly or less potentially hostile than
any other... Hard crunchy exterior and soft gooey center is best
reserved for candy-bars.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 14 Nov 2013 19:39:17 +0000

On Nov 14, 2013, at 12:56 AM, Mikael Abrahamsson <[email-masked]>
 wrote:

> By accepting SYN packets on port 80, you're soliciting connections. 

No. You are allowing someone else to successfully solicit (SYN) a connection to you. Sending a SYN is soliciting a connection.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 14 Nov 2013 11:48:02 -0800

> No. You are allowing someone else to successfully solicit (SYN) a connection to you. Sending a SYN is soliciting a connection.

If you are a listener new connections are unsolicited.

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Fri, 15 Nov 2013 20:02:45 +0200

First of all i would like to note that i find this draft very interesting, giving food for thought.
If this was going to be a BCP then i would have major objections. Since it's informational, it would be nice to see it published.

A general comment:

Personally i believe it's too early to decide on anything about IPv6 default security, especially when referring to devices "protecting" grandmas. The percentage of IPv6 eyeballs is way too low to change the current stateful "kind-of-protection", just based on the number/type of recorded ipv6 attacks. I don't see how can someone guarantee that in one year from now when a new exploit will have been found, it will be easily blocked using this type of protection.

Threats/attacks evolve at the same speed (or even faster) than the measures we take against them and moving to a default open policy gives them the advantage of knowing how to exploit these weaknesses easier. Instead of focusing on http/sql/rpc/etc attacks we might see other types of attacks rising from the bad guys, since we give them the space to do so. Also, having some means of a centralized homenet security device can be proved valuable, when all "protected" hosts are of different (and sometimes unknown) capabilities.

So, although i support this, i would like to see a note warning about some of the above dangers and noting that extra caution is to be used when following this.

And some specific comments:

>  The blocked inbound ports is expected to
>    be updated as threats come and go.

>    This document is applicable to off-the-shelves CPE as well to managed
>    Service Provider CPE or for mobile Service Providers (where it can be
>    centrally implemented).

>    The basic goal is to provide a pre-defined security policy which aims
>    to block known harmful traffic and allow the rest, restoring as much
>    of end-to-end communication as possible.  This pre-defined policy can
>    be centrally updated and could also be a member of a security policy
>    menu for the subscriber.

>    These example lists will probably evolve with the time as new
>    protocols and new threats appear.  The update of the specific rules
>    could be done by firmware upgrade, policy update (for example by
>    Broadband Forum TR-69).

Experience has shown than CPE updates from vendors are much slower than host updates, so i would expect that new threats would take a while to be fixed in the firmware. TR-069 would solve that only for managed CPEs, assuming a policy could be applied.

>    3.  Rule ProtectWeakServices: drop all inbound and outbound packets
>        whose layer-4 destination is part of a limited set (see
>        Section 3.2, the intent is to protect against the most common
>        unauthorized access and avoid propagation of worms (even if the
>        latter is questionable in IPv6); an advanced residential user
>        should be able to modify this pre-defined list;

Set is limited because of a specific reason? hw resources?
Comparing this implementation (default permit) with an opposite one (default deny), i would see much more deny entries in this than permit entries in the other. I can't predict the possible growth of each one, but i would give much more chances to denies than to permits.

>    The authors of the documents believe and the Swisscom deployment
>    shows that the following attack are mostly stopped:
>
>    o  Unauthorized access because vulnerable ports are blocked

It would be nice to have a report with some numbers backing this up.

--
Tassos

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 15 Nov 2013 18:35:11 +0000

> So, although i support this, i would like to see a note warning about some of the above dangers and noting that extra caution is to be used when following this.

Thanks.

Again, speaking as a participant.

Where I most scratch my head is that the threat the firewall presumably is intended to defend against, and the asset it is trying to defend, is not usually related to a protocol. If we decide that a given protocol number or port number is "universally OK", such as RFC 6092's comments on ESP/AH/IKE, one can expect port-agile attacks to use that port number for whatever protocol they use. If we say that we want a specified server to act as a listener for a protocol, such as a web server for http/https, that doesn't imply that all devices implementing listeners should be exposed as a matter of policy (if you have a Canon MP620 series printer or a Cisco telephone, and its address is X.X.X.X, open http://X.X.X.X, and ask yourself if that's information you want available to the world).

So, blocking a couple of ports doesn't seem to accomplish much from a security perspective. I'm not sure what I would call "security" in this draft, much less "balanced". What the draft does, as near as I can tell, is give service providers something that somebody called a firewall, so that they can tell their customers that have the presence of a firewall as a market requirement that they are deploying a firewall, but depending on their customers to be dumb enough to not realize that the firewall doesn't secure anything.

BTW, as chair, I have asked for a security directorate review of this draft.

---

From: "cb.list6" <[email-masked]>
Date: Fri, 15 Nov 2013 10:49:32 -0800

> So, blocking a couple of ports doesn't seem to accomplish much from a security perspective. I'm not sure what I would call "security" in this draft, much less "balanced". What the draft does, as ne…

Network operators who have deployed this strategy outlined in the
draft have penned the draft, they have to deal with the strain on
their network and helpdesk calls related to being hacked.

I believe the point of the draft is to share deployment experience
that there is no material change to the relevant network provider
metrics related to those costs of hacking.

If i understanding the scenario correctly, Swisscom had IPv4 NAT CPE
deployed with "stateful connection inspection" by default

They deployed IPv6 on a large scale without "stateful connection
inspection"  for IPv6 and the relevant metrics of attack traffic and
helpdesk calls have not changed.

This is not a matter of theory, this a matter of network operators
sharing operational experience for the betterment of other network
operators.

CB

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 15 Nov 2013 19:23:02 +0000

Well, that's one of the things the draft says. It also describes a security model that the IETF is intended to say is adequate for some purpose. It's that security model that I'm commenting on.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 15 Nov 2013 22:06:14 -0800 (PST)

----- Original Message -----
> From: cb.list6 <[email-masked]>
> To: Fred Baker (fred) <[email-masked]>
> Cc: "[email-masked] WG" <[email-masked]>
> Sent: Saturday, 16 November 2013 5:49 AM
>>>  So, although i support this, i would like to see a note warning about 
> some of the above dangers and noting that extra caution is to be used when 
> following this.
>> 
>>  Thanks.
>> 
>>  Where I most scratch my head is that the threat the firewall presumably is 
> intended to defend against, and the asset it is trying to defend, is not usually 
> related to a protocol. If we decide that a given protocol number or port number 
> is "universally OK", such as RFC 6092's comments on ESP/AH/IKE, 
> one can expect port-agile attacks to use that port number for whatever protocol 
> they use. If we say that we want a specified server to act as a listener for a 
> protocol, such as a web server for http/https, that doesn't imply that all 
> devices implementing listeners should be exposed as a matter of policy (if you 
> have a Canon MP620 series printer or a Cisco telephone, and its address is 
> X.X.X.X, open http://X.X.X.X, and ask yourself if that's information you 
> want available to the world).
>> 
>>  So, blocking a couple of ports doesn't seem to accomplish much from a 
> security perspective. I'm not sure what I would call "security" in 
> this draft, much less "balanced". What the draft does, as near as I 
> can tell, is give service providers something that somebody called a firewall, 
> so that they can tell their customers that have the presence of a firewall as a 
> market requirement that they are deploying a firewall, but depending on their 
> customers to be dumb enough to not realize that the firewall doesn't secure 
> anything.
>> 
> 

> helpdesk calls have not changed.

From the draft, 

"This model has been deployed successfully
   in Switzerland by Swisscom without any known security incident."

This is not evidence that this measure has been of any effect at all. Equally, IPv6's billions of billions times larger address space could also be the reason there has been no known security incident, as unsolicited inbound attacks are far, far less likely to be successful. Finally, there may have been a security incident, but Swisscom aren't aware of it. This is the "Correlation does not imply causation" trap.

To support their argument, I'd be looking to see the packet captures of the IPv6 packets aimed towards their subscribers, for the ports that they've blocked, before and after they've been blocked, to show that this security measure has been effective. This would have to be for IPv6 addresses that actually exist, otherwise it isn't evidence that an attack was prevented, just evidence that a packet was pro-actively dropped earlier than it would have been without the CPE filter.

I wouldn't object to this being published as an Information RFC, but I think it must only detail exactly what Swisscom did and their rational for doing so, and make it very clear that it is only what Swisscom did, not what the IETF suggest and recommend. To me it reads too much like the latter.

If this is to be published, then I think the following is an example of how. I don't really agree with what Comcast did (it's a man-in-the-middle attack), however I agree that it is useful to publish how one particular ISP has solved a particular problem.

Comcast's Web Notification System Design
http://tools.ietf.org/html/rfc6108

Regards,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 15 Nov 2013 22:30:13 -0800 (PST)

>To: Mikael Abrahamsson <[email-masked]> 
>Sent: Thursday, 14 November 2013 9:50 PM
>I realise now that "unsolicited" is a word allowing multiple interpretations (but also used in RFC 6092).  But we seem to have got it right.
>
>Anyway, the fact that some service, on an internal device, is willing to accept connections on port XYZ,
>does not, in my opinion, imply that those connections may also come from the outside Internet.
>suppose it has a service (port XYZ) that allows it to be queried for its contents.

>Probably great when one is at home, but does this mean accessible from anywhere on the Internet ?
>
>In my opinion : not before the owner has explicitly instructed his CPE to allow incoming connections (RFC 6092, REC-48).
>

Actually, I think you're probably going to want your refrigerator to be able to access the Internet, as well as your toaster, answering machine, rice cooker, washing machine etc.

I think appliances, if they aren't already, are going to become computers, with as much done via software/firmware as possible, instead of hardware, because hardware is much harder and more expensive to change, both during development and after it is sold to the customer.

However, software/firmware is still hard to change if the customer has to either take it back to the manufacturer, or plug a PC or USB stick into it to update the software/firmware. Having the device be able to update itself over the Internet will be both much more user/customer friendly and much cheaper for the manufacturer. 

So manufacturers have an incentive to make their appliances be able to attach to the Internet, and their customers have an incentive to attach them. As with tablets and smartphones, the manufacturer won't be able to vouch for the existence of any upstream network "firewalls", nor will they successfully be able to ask the customer of their existence, so the manufacturer will have to assume the worst, and therefore harden the appliance against publicly addressed unfettered Internet access.

Regards,
Mark.

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Fri, 15 Nov 2013 00:00:42 +0200

A general comment:

Personally i believe it's too early to decide on anything about IPv6 default security, especially when referring to devices "protecting" grandmas.
The percentage of IPv6 eyeballs is way too low to change the current stateful "kind-of-protection", just based on the number/type of recorded ipv6 attacks.
I don't see how can someone guarantee that in one year from now when a new exploit will have been found, it will be easily blocked using this type of protection.
Threats/attacks evolve at the same speed (or even faster) than the measures we take against them and moving to a default open policy gives them the advantage of knowing how to exploit these weaknesses easier.
Instead of focusing on http/sql/rpc/etc attacks we might see other types of attacks rising from the bad guys, since we give them the space to do so.
Also, having some means of a centralized homenet security device can be proved valuable, when all "protected" hosts are of different (and sometimes unknown) capabilities.

So, although i support this, i would like to see a paragraph warning about some of the above dangers and noting that extra caution is to be used when following this.

>        Section 3.2 <http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security-00#section-3.2>), the intent is to protect against the most common

--
Tassos

---

From: Ray Hunter <[email-masked]>
Date: Sun, 17 Nov 2013 18:25:41 +0100

> From my perspective, I think I would prefer that the firewall - if implemented - blocked everything, and applications within the network advised the firewall(s) of traffic that they are willing to…

I have read the draft.

Summary: I don't have answers to my own points below, but neither does
this draft, so whilst I welcome the authors sharing their experiences, I
can't support publishing it as-is as a v6ops WG document.

The bottom line is that I wouldn't be happy if my own ISP adopted the
policy exactly as-documented in the draft.

I think we probably need something more sophisticated. And being
realistic, we're probably not yet ready to write it.

Detailed Points (IMHO)

I don't think the threat model listed in the draft is particularly up to
date or complete.

1. Experience in enterprises has really convincingly demonstrated that
the firewall that switches off at 5pm is rather limited in it's efficacy
(mobile nodes that cross the border at night to travel home, and then
which re-enter the secure zone the next morning)

2. Trojanized hosts are pretty much impossible to stop.
Attempting to address or prevent covert channels is a red-herring on the
Internet, as they are inherently possible given the underlying Internet
architecture.
Preventing them would require )at least) the introduction of formal
message syntax (and timing) to every single protocol, and stifle innovation.

3. The concept of "inside" and "outside" is just too simplistic. Even in
a typical home network, there are going to be multiple classes of
devices. Some of which are going to have poorly maintained code that
never updates, and others that are going to be "on the Internet" 7x24
and are well-patched.

There are going to be network devices that control real physical objects
that may have a real-world financial or security impact if they are
controlled by an unauthorised person.

The vulnerability levels of these classes, and the impact of a
successful attack, is likely to be very different.

So a one-size-fits-all single-zone solution for Homenet is in itself
problematic IMHO.

4. There's no denying that blocking of port 25 has helped fight spam.
But it has also deprived many end-users of access to SMTP, and forced
them to use centralised services.

I think there's a very valid debate to be conducted about whether it is
the responsibility of an ISP to protect customers' devices, or to
protect their own network, or both, or neither. It isn't clear to me how
much of this draft is focussed on each of these goals.

5. A port-based model of application classification is outdated.

Almost everything runs on port 80 anyway today.
HTTP can be extremely useful for users.
But it can also be very harmful.

As has been pointed out by others, SNMPv3 is considered "secure". Yet it
uses the same ports as SNMPv1 and SNMPv2.
So blocking HTTP and SNMPv1 and SNMPv2 may be considered "helpful" to
the end user.
But blocking HTTP SNMPv3 may well be "harmful" and may deprive them of
Internet functionality.

6. Who determines what is weak?
SSH with plain text passwords and root access may be weak.
SSH with a certificate, and only authorised for certain users and
certain commands, has no such weakness AFAIK.

Life's a lot more complex than just blanket blocking a port for an
entire ISP network.

Are the ISP's going to conduct a Business Impact Analysis per end user?

7. Is the CPE the correct place to control access?
CPE's are some of the worst maintained code on the planet. So why try to
control access at this point?

8. The Internet is not homogenous.

There are end users that are experts, and there are end users who most
definitely aren't.

There are AS's that have very good record of tracking down bad-guys
backed up by law enforcements, and others that are not so good.

I'd like to see a threat model that also incorporates some form of
reputation of the local and remote users, e.g. via an AS source, or at
least address block.

Although of course I'd agree that's a bit of an ineffective
sledgehammer, it's still probably one step better than "allow all" or
"deny all".

That way the ISP could protect it's own equipment from locally infected
systems, without blocking traffic from users who are not infected, or
who have never caused a problem.

9. Is the underlying problem the network, the host implementation, or is
the vulnerability in the security model of the protocol itself?

There's a role for many parties to play here.
The IETF should probably be concentrating efforts on ensuring all core
protocols can survive on the Internet.
Network operators need to protect their own services.
And host vendors should not be shipping devices where vulnerable ports/
services are running by default.

-- 
Regards,
RayH

---

From: Marc Lampo <[email-masked]>
Date: Mon, 18 Nov 2013 08:42:07 +0100

Probably true - all of your points - but, INHO, this does not imply that
the Internet should get access by default to most ports.
And RFC 6092, REC-31 (for TCP), satisfies those needs.

But if the Internet can access an internal device, that should first be
allowed by the "operator" of the CPE, as per RFC 6092, REC-48.
And whoever is OK with that (open) policy, can make use of RFC 6092,
REC-49, and go for "transparent" mode.

I acknowledge other contributions in this list stating that any device can
end up with infected/hostile neighbors in the local network,
but is this a reason/excuse to have a "mostly open policy for incoming
traffic" ?

So, personally I cannot support publishing this draft as a WG document
because it is, at least partly - but then : on an important point,
in contradiction with RFC 6092.
I would be more in favor if the approach chosen (blocking some ports) would
have been to strengthen RFC 6092, REC-49 :
"transparent mode", but not for all ports.

On Sat, Nov 16, 2013 at 7:30 AM, Mark ZZZ Smith
<[email-masked]>wrote:

> Actually, I think you're probably going to want your refrigerator to be
> able to access the Internet, as well as your toaster, answering machine,
> rice cooker, washing machine etc.
>
> I think appliances, if they aren't already, are going to become computers,
> with as much done via software/firmware as possible, instead of hardware,
> because hardware is much harder and more expensive to change, both during
> development and after it is sold to the customer.
>
> However, software/firmware is still hard to change if the customer has to
> either take it back to the manufacturer, or plug a PC or USB stick into it
> to update the software/firmware. Having the device be able to update itself
> over the Internet will be both much more user/customer friendly and much
> cheaper for the manufacturer.
>
> So manufacturers have an incentive to make their appliances be able to
> attach to the Internet, and their customers have an incentive to attach
> them. As with tablets and smartphones, the manufacturer won't be able to
> vouch for the existence of any upstream network "firewalls", nor will they
> successfully be able to ask the customer of their existence, so the
> manufacturer will have to assume the worst, and therefore harden the
> appliance against publicly addressed unfettered Internet access.
>
> Regards,
> Mark.
>
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Nov 2013 03:09:01 -0500

> On Nov 18, 2013, at 2:42 AM, Marc Lampo <[email-masked]> wrote:
> 
> Probably true - all of your points - but, INHO, this does not imply that the Internet should get access by default to most ports.

If it doesn't it isn't on the Internet. 

Many devices are - at best - tethered to the Internet by a proxy.  But that doesn't make it either right or sufficient.  

> But if the Internet can access an internal device, that should first be allowed by the "operator" of the CPE, as per RFC 6092, REC-48.
> And whoever is OK with that (open) policy, can make use of RFC 6092, REC-49, and go for "transparent" mode.
> 
> I acknowledge other contributions in this list stating that any device can end up with infected/hostile neighbors in the local network,
> but is this a reason/excuse to have a "mostly open policy for incoming traffic" ?
> 
> So, personally I cannot support publishing this draft as a WG document because it is, at least partly - but then : on an important point,

See the beginning of sec 1.2 of that doc.  It informational only, despite the use of requirements language. 

> I would be more in favor if the approach chosen (blocking some ports) would have been to strengthen RFC 6092, REC-49 :

RFC 6092 carries zero weight. If you want to strengthen it, you need to start by having it be reconsidered and ultimately reissued as BCP or some such.  

Joe

> 
> 
>> On Sat, Nov 16, 2013 at 7:30 AM, Mark ZZZ Smith <[email-masked]> wrote:
>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 18 Nov 2013 09:19:52 +0100 (CET)

On Mon, 18 Nov 2013, Marc Lampo wrote:

> I acknowledge other contributions in this list stating that any device 
> can end up with infected/hostile neighbors in the local network, but is 
> this a reason/excuse to have a "mostly open policy for incoming traffic" 
> ?

It all comes down to "better safe than sorry" as opposed to "make things 
work without operator invention".

Do you want devices to be part of the Internet as default or not is the 
major philosophical question. Should devices have a one-way peep-hole to 
the Internet by default or should they be open and be reachable from the 
Internet by default. Gated community and don't care about locking your 
door because you trust the neighborhood, or open community and take care 
of your own security.

There is no right answer here, but I am in favour of the open variant and 
let hosts take care of their own security.

Most devices today are hardened enough to handle being exposed to the 
Internet, is my opinion. From your reasoning I guess you do not agree.

My background is that I worked for 7 years for a mobile operator that 
didn't have any filters apart from outgoing port 25 and a few other things 
(very similar to balanced security proposal). Even less for residential 
access. No bad effects from this even with millions of customers.

So I think it's up to the people who want to put filters in CPEs by 
default to prove that applications work well with this, and give advice to 
application implementers what they need to do in order to make things 
work. Do they need to do STUN-like functionality always, even though there 
is no NAT, just to make sure the stateful filtering device actually sees 
this as a wanted session?

---

From: "de Brün, Markus" <[email-masked]>
Date: Mon, 18 Nov 2013 11:37:21 +0100

> >[...], but does this mean accessible from anywhere on the Internet ?

> able to access the Internet, [...]

"Access to the internet" and "accessible from the internet" are two seperate 
things.Perhaps I want my fridge to access the internet but not the other way 
around.

There was a vulnerability in some heating-systems a few month ago [1]. An 
attacker could remotely shut down the heating. This is the kind of thing one 
does not want to happen.

Regards,
Markus

[1] 
http://www.heise.de/security/meldung/Vaillant-Heizungen-mit-Sicherheits-Leck-1840919.html

__________ ursprüngliche Nachricht __________

Von:		Mark ZZZ Smith <[email-masked]>
Datum:	Samstag, 16. November 2013, 07:30:13
An:		Marc Lampo <[email-masked]>, Mikael Abrahamsson 
<[email-masked]>
Kopie:	"[email-masked] WG" <[email-masked]>
Betr.:	Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC

> > accept connections on port XYZ, does not, in my opinion, imply that those
> > connections may also come from the outside Internet. Back to the example
> > with the refrigerator :

---

From: Marc Lampo <[email-masked]>
Date: Mon, 18 Nov 2013 11:44:51 +0100

Do I understand this is an argument against the "mostly open policy" of the
draft ?

(although the draft proposes to keep tcp port 80 closed and this particular
vulnerability seems to be against port 80)

On Mon, Nov 18, 2013 at 11:37 AM, de Brün, Markus <
[email-masked]> wrote:

> to

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 19 Nov 2013 11:09:30 -0800 (PST)

----- Original Message -----
> From: "de Brün, Markus" <[email-masked]>
> To: [email-masked]; Mark ZZZ Smith <[email-masked]>
> Cc: Marc Lampo <[email-masked]>; Mikael Abrahamsson <[email-masked]>
> Sent: Monday, 18 November 2013 9:37 PM
>>  >[...], but does this mean accessible from anywhere on the Internet ?
> 

It might depend on whether you want to find out what is in it when you're at the supermarket. It might be convenient to know if you need to buy milk when you're there.

> attacker could remotely shut down the heating. This is the kind of thing one 

True.

However, if you were the manufacturer of this heating system, how could you be sure your customers are not attaching the device directly to an unfettered Internet connection? You could try putting a warning on the box or in the manual saying "Don't plug into the Internet" or "There MUST be a firewall in front of this device." That might not confuse people like us, but I'm pretty sure it will confuse the majority of consumers.

The only way for a manufacturer to be sure of the security of the device is to assume the worst and have the device be totally self reliant for its Internet protection. If the manufacturer does that, then there are no warnings in the manual or on the box that may be ignored, or phone calls from confused customers. That was my experience with my "smart" Internet connected TV and Blu-ray player. I've 'nmap' scanned them, and they look as they they've been Internet hardened.

It is also worth keeping in mind that the CPE itself may not be perfectly secure, and may be a target itself. If it is compromised, then any protection it used to provide may now be gone. I'd forgotten about it, however the ISP I worked for in 2009 had quite a number of customers who's CPE was infected by this malware:

http://en.wikipedia.org/wiki/Psyb0t

IIRC, impacted customers numbered in the 100s, I suspect because the CPE model was quite old at that point (it was already being sold in 2005 when I started there), so many customers had replaced it. It would have remained unnoticed by both us and the customers if it hadn't caused customers' Internet connections to fail.

The Carna Botnet also leveraged insecure CPE to conduct the "Internet Census 2012", which I think is further evidence that there shouldn't be absolute faith in the security of CPE . (http://lists.ausnog.net/pipermail/ausnog/2013-September/020338.html)

So I think device manufacturers would be wise to make a device/appliance protect itself, even if they believe there commonly might be an upstream networking device perform some sort of firewalling function.

Regards,
Mark.

>>  >________________________________
>>  > From: Marc Lampo <[email-masked]>
>>  >To: Mikael Abrahamsson <[email-masked]>
>>  >Cc: "[email-masked] WG" <[email-masked]>
>>  >Sent: Thursday, 14 November 2013 9:50 PM
>>  >Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC
>>  >
>>  >
>>  >
>>  >I realise now that "unsolicited" is a word allowing multiple
>>  > interpretations (but also used in RFC 6092).  But we seem to have got 
> it
>>  > right.
>>  >
>>  >Anyway, the fact that some service, on an internal device, is willing 
> to
>>  > accept connections on port XYZ, does not, in my opinion, imply that 
> those
>>  > connections may also come from the outside Internet. Back to the 
> example
>>  > with the refrigerator :
>>  >suppose it has a service (port XYZ) that allows it to be queried for 
> its
>>  > contents.
>>  >
>>  >Probably great when one is at home, but does this mean accessible from
>>  > anywhere on the Internet ?
>>  >
>>  >In my opinion : not before the owner has explicitly instructed his CPE 
> to
>>  > allow incoming connections (RFC 6092, REC-48).
>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Nov 2013 15:50:41 +0900

> policy exactly as-documented in the draft.

Would you be happier if your ISP implemented the "simple security"
recommendations in RFC 6092 and dropped all unsolicited packets to your
network except IPsec?

> realistic, we're probably not yet ready to write it.

So let's not throw out the baby with the bathwater then? This group exists
to share operational experience, and that is what this draft does. It does
not make any recommendations; even the rules it presents are examples. I
can't see anyone construing this as a recommendation or endorsement of any
sort.

We published RFC 6092. Why shouldn't we publish this one? It seems to me
that there's no real difference between this document and RFC 6092;
fundamentally, they both simply describe a security profile without making
any claim about whether it is a recommended profile. If anything, at least
this one has the advantage that it was deployed before it was
standardized...

I support this document.

---

From: Marc Lampo <[email-masked]>
Date: Wed, 20 Nov 2013 09:01:27 +0100

This document states, for several recommendations in RFC 6092, exactly the
opposite of that document.

In addition, as I touched in my very first reaction, this draft lists a
number of threats - section 2.
But, in my opinion, none of those threats are addressed by the rules for
balanced security - section 3.1.
 (my first comment only referred to the last threat on covert channels, but
I must rephrase)

Only "unauthorised use of services" is partly addressed, by blocking access
to some ports.

The later users it might be misleading : like if implementing these
balanced security rules,
 something is done about those threats.

In reply to the question : yes, personally I would be happier if the ISP
dropped all unsolicited packets towards my network (except IPsec).
An analogy :
is the front door of your home locked when nobody is at home ?
or do you have locks on the door towards the living room, kitchen and
bedrooom (only)
 and allow free access to the bathroom ?
Perhaps proper use of the bathroom is not dangerous,
 but it the unknown visitor (ab)uses the electricity outlet in the bathroom
?

---

From: Ray Hunter <[email-masked]>
Date: Wed, 20 Nov 2013 09:10:30 +0100

> Lorenzo Colitti <mailto:[email-masked]>
> 20 November 2013 07:50

Yes.

Provided the ISP gave me the ability to override that default setting
(either via a web site, PCP, UPnP, or some other mechanism)

At least I'd know for certain what ISP settings I needed to override.

They could even ask me to sign in blood in advance that all risks to my
equipment were my risk.

Whereas with this draft, we're going to have to merge two
vaguely-defined and time-variant security policies (my policy and the
ISP's policy).
If I open port 25 and the ISP closes it, which setting takes precedence?
And if the order that the requests arrive is different?
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Nov 2013 17:10:59 +0900

> opposite of that document.

Which ones? Obviously you're not suggesting that RFC 6092 recommends that
unsolicited inbound packets be dropped by default, right? Because it
doesn't say that.

>  (my first comment only referred to the last threat on covert channels,
> but I must rephrase)
>

Do you have text to suggest?

> dropped all unsolicited packets towards my network (except IPsec).

And there are people in this working group that will never agree with you.
For example, I will never agree with you.

But fortunately, that has no relevance on this document. Since this
document does not recommend a security policy, saying "I don't like the
security policy" (which is your opinion, and one you're perfectly entitled
to) is not a valid reason not to publish this document.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Nov 2013 17:14:02 +0900

> At least I'd know for certain what ISP settings I needed to override.

Er... which is what this draft says?

   These are an example set of generic rules to be applied.  Each would
   normally be configurable, either by the user directly or on behalf of
   the user by a subscription service.

---

From: Marc Lampo <[email-masked]>
Date: Wed, 20 Nov 2013 10:37:13 +0100

Yes, RFC 6092 recommends that unsolicited packets be dropped by default !

  REC-34  By DEFAULT, a gateway MUST respond with an ICMPv6
           "Destination Unreachable" error code 1 (Communication with
           destination administratively prohibited), to any unsolicited
           inbound SYN packet after waiting at least 6 seconds without
           first forwarding the associated outbound SYN or SYN/ACK from
           the interior peer.

"transparent mode" "MAY" be the default (which, in the context, I interpret
as a kind of "second choice")

   REC-49  Internet gateways with IPv6 simple security capabilities MUST
           provide an easily selected configuration option that permits
           a "transparent mode" of operation that forwards all
           unsolicited flows regardless of forwarding direction, i.e.,
           not to use the IPv6 simple security capabilities of the
           gateway.  The transparent mode of operation MAY be the
           default configuration.

On Wed, Nov 20, 2013 at 9:10 AM, Lorenzo Colitti <[email-masked]> wrote:

>> This document states, for several recommendations in RFC 6092, exactly
>> the opposite of that document.
>>
>
>>  But, in my opinion, none of those threats are addressed by the rules
>> for balanced security - section 3.1.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 20 Nov 2013 11:01:28 +0100

> 20 November 2013 09:14
So what does the draft really say?

Here's some filtering rules, that you may or may not like, which may or
may not be overridden, which may change over time, which only mitigate a
very limited number of threats, and maybe the ISP will manage the
security policy but maybe the end user wants to take this responsibility
......

Where's the evidence to say that this approach is any better than an
open security policy of "allow everything bi-directionally" ?

The threats are listed in the draft as:

   o  denial of service by packet flooding: overwhelming either the
      access bandwidth or the bandwidth of a slower link in the
      residential network (like a slow home automation network) or the
      CPU power of a slow IPv6 host (like networked thermostat or any
      other sensor type nodes);

not covered.

   o  denial of service by Neighbor Discovery cache exhaustion
      [RFC6583]: the outside attacker floods the inside prefix(es) with
      packets with a random destination address forcing the CPE to
      exhaust its memory and its CPU in useless Neighbor Solicitations;

not covered.

   o  denial of service by service requests: like sending print jobs
      from the Internet to an ink jet printer until the ink cartridge is
      empty or like filing some file server with junk data;

not covered.e.g. port 515

   o  unauthorized use of services: like accessing a webcam or a file
      server which are open to anonymous access within the residential
      network but should not be accessed from outside of the home
      network or accessing to remote desktop or SSH with weak password
      protection;

not covered. e.g. port 8080.

   o  exploiting a vulnerability in the host in order to get access to
      data or to execute some arbitrary code in the attacked host such
      as several against old versions of Windows;

not covered.

   o  trojanized host (belonging to a Botnet) can communicate via a
      covert channel to its master and launch attacks to Internet
      targets.

not covered.

And in the Security section, the draft only addresses "Unauthorized
access because vulnerable ports are blocked" ?

IMHO this threat is anyway blocked by machine firewalls running on every
modern OS shipping today (any device that is likely to support IPv6)

-- 
Regards,
RayH

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Nov 2013 19:01:43 +0900

It's not a second choice:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.

So no, RFC6092 and this document do not disagree. If you read the MAY in
REC-49 as "is", then the two documents are compatible (the other point you
cite, REC-34, is sort of irrelevant at that point).

On Wed, Nov 20, 2013 at 6:37 PM, Marc Lampo <[email-masked]>wrote:

> "transparent mode" "MAY" be the default (which, in the context, I
> interpret as a kind of "second choice")
>
> On Wed, Nov 20, 2013 at 9:10 AM, Lorenzo Colitti <[email-masked]>wrote:
>
>> And there are people in this working group that will never agree with
>> you. For example, I will never agree with you.
>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Nov 2013 19:17:31 +0900

> security policy but maybe the end user wants to take this responsibility

Pretty much. Oh, and "this ISP has rolled it out and has not seen any
issues so far".

> open security policy of "allow everything bi-directionally" ?

None, but none is required because nobody is trying to make such a
statement. Which is good, because there is zero chance of this or any other
IETF working group (or actually, any group of more than... oh, about 3
engineers) agreeing on such statement.

>       covert channel to its master and launch attacks to Internet

Right. And the draft doesn't claim that to addresses those threats.

> access because vulnerable ports are blocked" ?

Yep. As the abstract says, it's a balance.

But the point about this draft is not the filtering policy itself, and in
fact, the document makes no claims about what the policy should be. (This
is good, because there's no chance of the WG ever agreeing on any specific
policy.) It simply says, "here are some threats. here's what we rolled out.
here's what we found out." IMO this is perfectly acceptable for an
operational group such as this one, and it is of value because it
represents real operational experience.

> modern OS shipping today (any device that is likely to support IPv6)

I agree with you, but good luck finding lots of other people who do.

As an aside, I'm confused how can you simultaneously make the argument that
the draft doesn't cover port 515 and port 8080, and then in the same breath
say that that threat is blocked anyway by any device that is likely to
support IPv6. But again, neither is really the point of this draft.

Cheees,
Lorenzo

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Nov 2013 08:42:47 +1300

>            first forwarding the associated outbound SYN or SYN/ACK from

Er, no, it recommends that unacknowledged unsolicited SYNs should cause
Destination Unreachable, if no TCP listener has responded after 6 seconds.
The gateway isn't dropping anything. It is required to be stateful for
6 seconds in case there is a response.

> as a kind of "second choice")

That interpretation is not justified by RFC 2119.

   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 20 Nov 2013 11:52:17 -0800 (PST)

> From: Lorenzo Colitti <[email-masked]>
>To: Marc Lampo <[email-masked]> 
>Cc: Ray Hunter <[email-masked]>; "[email-masked] WG" <[email-masked]> 
>Sent: Wednesday, 20 November 2013 7:10 PM
>On Wed, Nov 20, 2013 at 5:01 PM, Marc Lampo <[email-masked]> wrote:
>
>This document states, for several recommendations in RFC 6092, exactly the opposite of that document.
>>
>
>
>Which ones? Obviously you're not suggesting that RFC 6092 recommends that unsolicited inbound packets be dropped by default, right? Because it doesn't say that.
> 
>In addition, as I touched in my very first reaction, this draft lists a number of threats - section 2.
>>But, in my opinion, none of those threats are addressed by the rules for balanced security - section 3.1.
>> (my first comment only referred to the last threat on covert channels, but I must rephrase)
>>
>
>
>In reply to the question : yes, personally I would be happier if the ISP dropped all unsolicited packets towards my network (except IPsec).
>>
>
>
>And there are people in this working group that will never agree with you. For example, I will never agree with you.
>
>
>But fortunately, that has no relevance on this document. Since this document does not recommend a security policy, saying "I don't like the security policy" (which is your opinion, and one you're perfectly entitled to) is not a valid reason not to publish this document.
>

With a title like "Balanced Security for IPv6 Residential CPE" it has strong overtures of being IETF recommendations.

With a title like "Swisscomm's IPv6 CPE Firewalling Policy Deployment", it doesn't.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 20 Nov 2013 12:05:41 -0800 (PST)

>To: Ray Hunter <[email-masked]> 
>Sent: Wednesday, 20 November 2013 9:17 PM
>Pretty much. Oh, and "this ISP has rolled it out and has not seen any issues so far".
> 

How do they know? What methods have they used to be sure of that? All it sounds like is that they've passively waited for any complaints after deploying this, and as they haven't heard any, they've decided that the _only reason_ they haven't heard complaints is because their measure has worked. That is not evidence.

How do they know IPv6's large address space isn't the actual thing that has prevented their customers being attacked?

How do they know that host based firewalls isn't the reason that there hasn't been a successful attack?

How do they know that there hasn't been an attack, and it is just that they don't know about it? 

Where is the _measurement_ of the effectiveness or not of this, and where is the evidence that some other measure isn't the reason that there haven't been any known attacks?

>None, but none is required because nobody is trying to make such a statement. Which is good, because there is zero chance of this or any other IETF working group (or actually, any group of more than... oh, about 3 engineers) agreeing on such statement.
> 
>But the point about this draft is not the filtering policy itself, and in fact, the document makes no claims about what the policy should be. (This is good, because there's no chance of the WG ever agreeing on any specific policy.) It simply says, "here are some threats. here's what we rolled out. here's what we found out." IMO this is perfectly acceptable for an operational group such as this one, and it is of value because it represents real operational experience.
>
>
>As an aside, I'm confused how can you simultaneously make the argument that the draft doesn't cover port 515 and port 8080, and then in the same breath say that that threat is blocked anyway by any device that is likely to support IPv6. But again, neither is really the point of this draft.
>
>
>Cheees,
>Lorenzo
>

---

From: Marc Lampo <[email-masked]>
Date: Thu, 21 Nov 2013 07:51:29 +0100

A pity that the text can be interpreted in various ways and that those lead
to completely opposite results.

(written by a politician ? ;-)

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Nov 2013 15:56:41 +0900

On Thu, Nov 21, 2013 at 3:51 PM, Marc Lampo <[email-masked]>wrote:

> A pity that the text can be interpreted in various ways and that those
> lead to completely opposite results.
>

So can the text, "Here's how to configure the firewall. The firewall can be
turned on or off."

---

From: Ray Hunter <[email-masked]>
Date: Thu, 21 Nov 2013 08:31:14 +0100

> With a title like "Swisscomm's IPv6 CPE Firewalling Policy Deployment", it doesn't.
+1

Would this be better as an individual submission instead of a v6ops WG doc?

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Nov 2013 08:23:46 +1300

> to completely opposite results.

Well yes, I'd say that text is unclear and should have been fixed before
publication. However, when you think of how to implement it, the requirement
to wait at least 6 seconds tells you that (a) the firewall is stateful and
(b) there might be a response packet coming, so the firewall must have
forwarded the incoming SYN.

> (written by a politician ? ;-)

No, just a careless engineer, and reviewed by other careless engineers!
We all share the blame ;-)

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Thu, 21 Nov 2013 21:21:07 +0100

> 20 November 2013 11:17

> represents real operational experience.

Thanks to the authors for sharing experiences, and kudos to them, but I
am still confused about why this draft should be stamped approved as a
v6ops WG document, because it hasn't really been widely debated as a
generic security model, and it seems more geared to describing what one
provider has done.

> support IPv6. But again, neither is really the point of this draft.

<operational hat> There is nothing to say that an ACL on a router and an
end user device are mutually exclusive, depending on whose security
model you are implementing (ISP's or end user's).

But IMHO "Half an ACL" is worse than no ACL at all, or a complete
blocking ACL:  It stops legitimate users performing their normal tasks,
whilst leaving the system wide open to the abusers. And it's a complete
pain to debug or explain to a help desk or users. If you're going to
block a function because it's a threat, then block all of the associated
ports.

Thinking about this further: if port 8080 and 443 were open for the
duration of this trial, and there were no incidents,  doesn't that
rather suggest that there were no real issues with allowing incoming
sessions to web servers in general, and thus the block on port 80 was in
fact redundant?

Similarly if LPD was open for the duration of the trial, doesn't it
suggest that there was no real problem with remote (ab)users printing to
customer's printers?

regards,

-- 
Regards,
RayH

---

From: "cb.list6" <[email-masked]>
Date: Thu, 21 Nov 2013 14:40:03 -0800

> > A pity that the text can be interpreted in various ways and that those
lead
> We all share the blame ;-)

Well.  The stateful inspection debate did not have a strong consensus then,
like now.

When consensus is weak, the guidance is weak. Death by 1,000 cuts.

Many network operators think stateful inspection is an Achilles heel of a
network and an affront to the internet model (me) .Others think it is a
"must have"  .

The ietf should not guide either way since there is no strong consensus.

This I-D is very useful for networks that choose no stateful inspection of
ipv6 -- including me, Swisscom,  Alitbox...

CB

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Nov 2013 11:52:31 +1300

On 22/11/2013 09:21, Ray Hunter wrote:
...
> generic security model, and it seems more geared to describing what one

That's exactly what it says, and it would be published as Informational,
tagged with the "IETF Stream" boilerplate.

Of course there's an alternative, resubmitting it to the Independent
Submission stream, probably with the word "Swisscom" prepended to the
title. Then it would appear with different boilerplate, but the magic
words "This document is not an Internet Standards Track specification"
would still appear.

    Brian