Subject: draft-ietf-v6ops-cpe-simple-security-06

From: james woodyatt <[email-masked]>
Date: Thu, 18 Jun 2009 16:11:54 -0700

everyone--

Our last adventure with this draft was over a month ago, and I've  
recently updated the draft in response to the comments that came up in  
the working group at the time.  I think I covered all the outstanding  
issues, but there might still be some points of controversy remaining  
to discuss.

I'd like very much to have all the remaining issues resolved before I  
travel to Stockholm.  Would the Chair please invite the working group  
to give this latest revision some consideration along the lines of  
another Last Call or whatever is appropriate?  Thanks.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Rémi Després <[email-masked]>
Date: Fri, 26 Jun 2009 16:08:47 +0200

James,

After reading draft-ietf-v6ops-cpe-simple-security-05, I am convinced  
that a even lower security level is worth adding to the draft.
It would be much simpler, but yet sufficient for many unmanaged sites.
Also, it could be deployed more rapidly, possibly without needing a  
major release in some CPEs.

In your draft, it could be added as "minimal security" (for example),  
to distinguish it from "simple security".

SPECIFICATION

The IPv6 "minimal" security protection is defined as follows:

Rx. An incoming IPv6 packet MUST BE REJECTED if it has a destination  
port that is:
- a well known or registered port (i.e. is < 49152), and
- not explicitly authorized for IPv4 port forwarding .

Ry. An incoming IPv6 packet MUST BE FORWARDED if:
- it is not subject to R1, and
- it's source address is anycast and doesn't start with the site IPv6  
prefix.

ORIGIN OF THE PROPOSAL

In my home office, the CPE offers native IPv6 without any IPv6- 
specific security mechanism.
This is acceptable for my daily use of IPv6 because the internal  
firewall of my computer (a Mac) is active.

But I once faced the following security problem (which could be  
permanent if it had not been for a temporary experiment):
- I had to open the Mac to incoming VNC connections from another  
computer of the site.
- If I had opened the VNC port in the Mac without disabling IPv6,  
this would have opened it also for connections from any host of the  
IPv6 global Internet.
- I therefore had to first deactivate IPv6 in the Mac (and reactivate  
it when I could close again the VNC port in the Mac).

In IPv4, there is no such problem because the NAT filters incoming  
packets having the VNC port as destination port (among many others).

DISCUSSION

With just rules Rx and Ry above, the level of security achieved,  
although not identical with that  achieved in IPv4 with CPE NATs, is   
similar.
A tentative incoming connection in IPv6 on a dynamic port would not  
be filtered by the CPE (as it is in IPv4 by the CPE NAT) but,  
matching no existing connection in the destination host, would be  
ignored there.
With this minimal IPv6 security, the risk that early IPv6 users face  
bad security surprises can be eliminated without waiting for the  
deployment of more flexible filtering mechanisms like that described  
in your draft.

Personally, I  miss this minimal level of protection.
I also believe that, in the foreseeable future, it will remain  
sufficient for me.

Thoughts?

Regards,

RD

Le 19 juin 09 à 01:11, james woodyatt a écrit :

> recently updated the draft in response to the comments that came up  
> in the working group at the time.  I think I covered all the  
> outstanding issues, but there might still be some points of  
> controversy remaining to discuss.
>
> I'd like very much to have all the remaining issues resolved before  
> I travel to Stockholm.  Would the Chair please invite the working  
> group to give this latest revision some consideration along the  
> lines of another Last Call or whatever is appropriate?  Thanks.
>
>
> --

---

From: Gert Doering <[email-masked]>
Date: Fri, 26 Jun 2009 17:50:29 +0200

Hi,

> this would have opened it also for connections from any host of the  

I'd argue that this is something that should be improved in the 
"host firewall" - instead of "completely closed" and "opened from 
everywhere", there should be a third state "open for connections from the 
local network"...

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jun 2009 07:57:14 +0100

> everywhere", there should be a third state "open for connections from the 

s/local network/trusted zone/ and this reflects the behaviour of at
least one very popular personal firewall. I think this is proven safe
practice, and actually means that with such a personal firewall
installed, the CPE can be wide open. Needless to say, this level
of on-board protection is essential for roaming anyway.

I'd certainly want my CPE to have an option to switch off all
firewall behaviour.

    Brian

---

From: Rémi Després <[email-masked]>
Date: Sat, 27 Jun 2009 11:13:09 +0200

>> everywhere", there should be a third state "open for connections  

Same view.
As a matter of fact, I sent a security bug report to Apple suggesting  
it.

However,  the possibility of a minimal security protection in CPEs  
should IMHO be _also_ available:
- for hosts that don't have good enough firewalls;
- for sites where there are several links and where some ports have  
to be open for link to link connections.

> installed, the CPE can be wide open.

Agreed, but applicable only if one can be sure that all hosts of the  
site, permanent and temporary, have good enough host firewalls.

> Needless to say, this level

Doesn't it depend on what is meant by "this level"?
(When roaming, closing all ports for ALL incoming calls is typically  
sufficient. Opening some of them only for  intra-link connections is,  
in my understanding, for hosts in well known sites.)

> I'd certainly want my CPE to have an option to switch off all

Agreed, provided the default behavior of unmanaged CPEs remains with  
a minimal security provision for IPv6.

RD

---

From: Christian Huitema <[email-masked]>
Date: Sat, 27 Jun 2009 15:22:15 +0000

> a minimal security provision for IPv6.

Why? If the users says "off", that ought to mean "off". Period. Not some kind of halfway on.

-- Christian Huitema

---

From: Fred Baker <[email-masked]>
Date: Sat, 27 Jun 2009 08:50:38 -0700

> I'd certainly want my CPE to have an option to switch off all

speaking commercially, I would not want to have to sell equipment with  
and without the firewall capability in separate packages either. I  
would want to be able to structure the network in a home even if I had  
a firewall at its edge.

---

From: james woodyatt <[email-masked]>
Date: Sun, 28 Jun 2009 09:43:50 -0700

On Jun 26, 2009, at 07:08, Rémi Després wrote:
>
> After reading draft-ietf-v6ops-cpe-simple-security-05, I am  
> convinced that a even lower security level is worth adding to the  
> draft.
> [...]
> Thoughts?

Let me begin by saying that I have no objection whatever to the  
proposal of lowering the level of security provided by the "simple  
security" function we're trying to document in this draft.  Writing  
here as an individual IETF contributor, i.e. without my editor hat, I  
have always opposed this simple security function for a variety of  
reasons that don't bear repeating in this thread.  My preference is  
for no default stateful filtering function in simple residential  
gateways.

All that said, however, I don't see how any "lower level of security"  
than described here is compatible with the level recommended in RFC  
4864, which was the starting point for this work.  If we're going to  
diverge from that baseline, then I'd expect that work would have to be  
the subject of an rfc4864bis draft, or at least a draft marked as an  
Update to RFC 4864, which this draft is most definitely not.  At  
least, not yet.

Shorter james: I have no technical objection to the proposal, but my  
editorial judgment is that it isn't appropriate to make it an  
amendment to this draft.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Jun 2009 08:13:39 +0100

Hi James,

On 2009-06-28 17:43, james woodyatt wrote:
...

> Update to RFC 4864, which this draft is most definitely not.  At least,
> not yet.
> 
> editorial judgment is that it isn't appropriate to make it an amendment
> to this draft.

4864 is Informational and this draft is currently tagged with
Intended status: Informational, so we don't have to be legalistic
about requirements. I think this issue could be resolved
by adding to this sentence in the Introduction:

>    In particular, extra care should be taken in designing the baseline
>    operating modes of unconfigured devices, since the security functions
>    of most devices will never be changed from their factory set default.

For example

   The designers of such devices should nevertheless provide user settable
   options for users who wish to increase or decrease the level of
   protection.

       Brian

---

From: Rémi Després <[email-masked]>
Date: Mon, 29 Jun 2009 10:08:12 +0200

> If the users says "off", that ought to mean "off". Period. Not some  
> kind of halfway on.
Sure. (I have nothing to say to the contrary.)

Brian asks for a way to "switch off" firewall behaviors.
I do APPROVE the proposal.

My point is that, for completely UNMANAGED  operation (turning an  
option is a management action), CPEs should have the following  
minimal IPv6 security :

***An incoming IPv6 packet  MUST BE REJECTED if its destination port  
is a well known or registered port  that has not  been authorized for  
IPv4 port forwarding.***

This IPv6 rule is stateless and extremely simple to implement.
In my understanding, it provides in IPv6 a protection that is  
similar  to that implicitly provided by IPv4 NATs  and that, with  
computer OSes as they are, is needed in some cases (as documented in  
a previous mail).

Comments on what this minimal protection would be missing for typical  
unmanaged sites (or comments of support) would be constructive... and  
very welcome.

Regards,

RD

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Jun 2009 16:16:45 +0000

> is a well known or registered port  that has not  been authorized for

There is no agreement as to what a "well known registered port" means. Your original e-mail mentioned all numbers below 49152. Operating system have various definition for these random port number ranges. Windows XP, for example, would allocate random number in the 4096-65536 range. Your proposed rule would break many applications that use random port numbers for things like instant messaging or VoIP.

-- Christian Huitema

---

From: Rémi Després <[email-masked]>
Date: Mon, 29 Jun 2009 19:33:41 +0200

Le 29 juin 09 à 18:16, Christian Huitema a écrit :

> There is no agreement as to what a "well known registered port" means.
> Your original e-mail mentioned all numbers below 49152.

I was relying what IANA says (ref. www.iana.org/assignments/port- 
numbers), namely:
- The Well Known Ports are those from 0 through 1023.
- The Registered Ports are those from 1024 through 49151

> Operating system have various definition for these random port  
> number ranges. Windows XP, for example, would allocate random  
> number in the 4096-65536 range. Your proposed rule would break many  
> applications that use random port numbers for things like instant  
> messaging or VoIP.

I see.
This does defeat the proposal as is.
Thanks for the info.

RD