Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07

From: Mark Baugher <[email-masked]>
Date: Mon, 3 Aug 2009 15:19:56 -0700

On Jul 31, 2009, at 4:56 AM, james woodyatt wrote:

> I think it should suffice to delete the second sentence from R41  
> entirely.  It would then read as follows:
>
>   R41: Gateways SHOULD implement a protocol to permit applications to
>   solicit inbound traffic without advance knowledge of the addresses  
> of
>   exterior nodes with which they expect to communicate.

Why do we recommend this function for IPv6?

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Aug 2009 11:46:48 +1200

On 2009-08-04 10:19, Mark Baugher wrote:
>>   solicit inbound traffic without advance knowledge of the addresses of

How else would you deal with a CPE firewall that has default deny
for incoming packets? Manual config?

   Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 3 Aug 2009 18:16:02 -0700

> for incoming packets? Manual config?

That may be precisely the point of Mr. Baugher's question.

At the IETF 75 social event, I got to talking with Paul Hoffman [VPN  
Consortium] about this topic.  It seemed to me that he was quite  
seriously suggesting services like <http://portforward.com/> are all  
anyone on the Internet really needs for this purpose.  As an  
individual contributor, such suggestions fill me with a nihilistic  
despair.  As the editor of this draft, however, I take them as  
seriously as they seem to be offered.

Given that we don't have a standards-track protocol we feel  
comfortable recommending, I'm not sure R41 as currently worded is  
really any better than making no recommendation at all and telling  
Internet application developers that they should just wait for portforward.com 
  to get around to supporting IPv6 routers in its PFConfig application.

The best argument I have for what I original wrote for R41 is that I  
think <portforward.com> and its PFConfig application are Lovecraftian  
horrors whose very existence is proof of IETF's deep and abiding  
hatred of common people.  I think we will all go to our graves in  
shame and dishonor if we don't try to prevent the mass psychic abuse  
inherent in what <portforward.com> exists to facilitate from happening  
again with IPv6 CPE like it does now for IPv4/NAT CPE.  But, that's my  
personal opinion.  I recognize my argument is not very persuasive to a  
significant fraction of the working group participants.

This was why I polled the working group about the option of simply  
deleting R41 from this draft.  Sadly, no consensus seemed to emerge.   
So, again, I'd like to invite further discussion from all those people  
who chose to hum for one of the alternatives I presented to the option  
of removing R41 from the draft.  What is it you really want?

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

---

From: Mark Baugher <[email-masked]>
Date: Mon, 3 Aug 2009 21:02:43 -0700

> for incoming packets? Manual config?

Manual config can at least be authenticated.  Conficker reportedly  
uses UPnP NAT traversal on IPv4 home networks and could have just as  
easily used NAT-PMP.  So we're recreating this issue in IPv6 unless we  
authenticate such requests.  How much worse off are we with no  
firewall than with one where practically any piece of malware can open  
it.

Besides that, I understand R15 and R27 to say that these shoulds would  
allow unsolicited inbound packets directed to an internal address, so  
long as the packets use TCP or UDP - if I'm reading them correctly.

Finally, it's not clear to me who the intended audience is for R41.   
We don't want every vendor of a CPE to invent their own firewall  
control solution.  It's something that the various standards  
developing organizations need to consider doing.  I'm looking at  
James' draft as recommendations for CPE vendors, OSS developers, and  
skilled users.

Mark

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 04 Aug 2009 08:56:54 +0200

> it.

That's just NOT TRUE. Typically the trust between your CPE and your

computer comes ENTIRELY from the fact that the computer is behind the CPE.

If you computer is already infected, then you are already screwed.

Certainly the CPE should protect itself from the computer, but it cannot

protect the rest of the internal network, especially not the already

infected computer.

As for UPnP-IGD and NAT-PMP... if Conficker is already behind the CPE, it

can use UDP or make outbound connections anyway. The hole punching protocol

just makes it more slightly more convenient for the worm.

-- 

Rémi Denis-Courmont

---

From: Mark Smith <[email-masked]>
Date: Tue, 4 Aug 2009 20:23:13 +0930

On Tue, 04 Aug 2009 08:56:54 +0200

> just makes it more slightly more convenient for the worm.

Completely agree.

Looking at netbooks with wired, wifi, bluetooth, and 3G or Wimax
connectivity, or Smartphones with wifi, 3G or Wimax connectivity, the
only safe thing to do is to have each host protect itself, because at
any time there could be multiple candidate access methods for
Internet access (and IEEE 802.21 (described in the recent Internet
Protocol Journal) is trying to make which one is currently being used
transparent). Even better is to have the applications protect
themselves, like ssh does ("If you want something done properly, you
need to do it yourself").

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 5 Aug 2009 00:39:16 +0300

At the risk of repeating a banality, "the only safe thing" is defense in
depth. We need to both have applications secure themselves, and, where
possible, require the CPE to provide additional protection.

And I'll second Remi's opinion, a firewall that can be manipulated by
malware is better than no firewall at all. Microsoft's native firewall adds
security to the host even though applications can punch holes through it.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mark Smith
> Sent: Tuesday, August 04, 2009 13:53
> To: Rémi Denis-Courmont
> Cc: Mark Baugher; Brian E Carpenter; james woodyatt; IPv6 Operations
> Subject: Re: R41 in draft-ietf-v6ops-cpe-simple-security-07
> 
> Scanned by Check Point Total Security Gateway.

---

From: Mark Baugher <[email-masked]>
Date: Tue, 4 Aug 2009 14:55:08 -0700

On Aug 4, 2009, at 2:39 PM, Yaron Sheffer wrote:

> malware is better than no firewall at all.

If we're going to design firewall control for IPv6, whether it be  
something new like ALD or an obvious extension to what's done for  
IPv4, I think it should default to authenticated firewall control.  In  
other words, I would not start with standardizing an unauthenticated  
firewall control mechanisms and assume that others will figure out how  
to add access controls.  Letting malware use UPnP NAT traversal or NAT- 
PMP as done today is a pretty low standard for a CPE interface that  
IMHO we should not accept going forward.  We'd like the CPE to refuse  
commands from malware.

Mark

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 5 Aug 2009 01:03:55 +0300

Hi Mark,

My security reflexes tell me that authenticated is better than un-, and I
agree that the protocol MUST support such a mode. But in practice, this
protocol will be used by applications, which most likely will store the auth
credentials somewhere. Malware can subvert the applications and/or get
directly at the credentials. At which point I'm not sure this is so secure
any more.

Thanks,
	Yaron

> From: Mark Baugher [mailto:[email-masked]]
> Sent: Wednesday, August 05, 2009 0:55
> To: Yaron Sheffer
> Cc: Mark Smith; Rémi Denis-Courmont; Brian E Carpenter; james woodyatt;
> IPv6 Operations
> References: <[email-masked]> <029CBD08-5A79-
> [email-masked]>
> <[email-masked]>
> <[email-masked]> <35FFC80F-07B3-4CE3-BF7A-
> [email-masked]> <[email-masked]>
> <[email-masked]> <AD7A13B1-C0F5-4C84-845C-
> [email-masked]> <440B7E43-76B7-4C18-A93E-
> [email-masked]> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK-
> EUMSG-01.mgdnok.nokia.com> <C79965AE-2C69-4A63-8EB7-
> [email-masked]> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK-
> EUMSG-01.mgdnok.nokia.com> <57D79623-D8A1-41E9-9FB8-
> [email-masked]> <[email-masked]>
> <[email-masked]> <3BF326F1-3AF5-4577-8409-
> [email-masked]> <[email-masked]>
> <[email-masked]
> > <7F9A6D26EB51614FBF9F81C0DA4CF!
>  [email-masked]>
> X-Mailer: Apple Mail (2.935.3)
> Return-Path: [email-masked]
> X-OriginalArrivalTime: 04 Aug 2009 21:56:24.0954 (UTC)
> FILETIME=[692B05A0:01CA154E]
> 
>

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 04 Aug 2009 15:15:32 -0700

Mark Baugher <[email-masked]>:
> Letting malware use UPnP NAT traversal or NAT-PMP as
> done today is a pretty low standard for a CPE interface that IMHO we
> should not accept going forward.  We'd like the CPE to refuse commands
> from malware.

What's the difference between a user and malware?

---

From: james woodyatt <[email-masked]>
Date: Tue, 4 Aug 2009 15:57:34 -0700

On Aug 4, 2009, at 15:03, Yaron Sheffer wrote:
> From: Mark Baugher [mailto:[email-masked]] (Sent: Wednesday,  
> August 05, 2009 0:55)
>>> And I'll second Remi's opinion, a firewall that can be manipulated  
>>> by malware is better than no firewall at all.
>>
>> IPv4, I think it should default to authenticated firewall control.   
>> [...]
>
> credentials somewhere. [...]

No.  The most like scenario is applications soliciting any-source  
inbound traffic will use techniques like RFC 5389 modulo NAT, and  
because there is no standard for choosing an exterior filtering  
regime, applications will then perform filter-state behavior tests and  
use rendezvous services when the exterior filtering regime isn't  
endpoint-independent.  This will end up costing battery and network  
resources that would otherwise not be spent if there was a protocol  
like R41 recommends, but it will work, it will be simple and it won't  
require any authentication credentials that users may or may not  
possess, much less remember where they wrote them down.

The point of allowing passive listeners to solicit any-source incoming  
flows with something like ALD has *always* been to make more wasteful  
techniques like RFC 5389 modulo NAT completely unnecessary.  Does this  
need to be spelled out more clearly in the draft?

---

From: Mark Baugher <[email-masked]>
Date: Tue, 4 Aug 2009 16:44:13 -0700

hi Yaron

On 4/08/2009, at 3:03 PM, Yaron Sheffer wrote:

> credentials somewhere.

Right.  And the application can be running on a platform that has no  
malware
problem, a small potential for malware problems, or very big malware  
problems.

> Malware can subvert the applications and/or get

On a platform that has very big malware problems, like we have today,  
the
use of access controls raises the bar:  For the malware to manipulate  
the
firewall, it must get installed on a device that has a credential, and  
it
must be a device from which it can obtain the credential and use it.  In
other words, just getting installed on a device is not enough; the  
malware
needs to get installed on a device authorized to do firewall control.

Furthermore, I would not rule out advances in the state of the art, such
as devices that are not prone to malware or new authentication  
techniques
that defeat malware.  CAPTCHA is one such technique that is widely  
reputed
to be broken.  But I would not rule out novel uses of old methods like
CAPTCHA, which might be harder to defeat when run from the network
gateway device.

Mark

>> <[email-masked] 
>> >
>> [email-masked]> <[email-masked] 
>> >
>> [email-masked]>  
>> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044EB32@NOK-
>> [email-masked]>  
>> <18034D4D7FE9AE48BF19AB1B0EF2729F3A7044F238@NOK-
>> [email-masked]> <[email-masked] 
>> >
>>> by
>> In

---

From: Mark Baugher <[email-masked]>
Date: Tue, 4 Aug 2009 16:45:32 -0700

> What's the difference between a user and malware?

I just posted replied to another note regarding this.

Mark

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 05 Aug 2009 08:41:50 +0200

On Wed, 5 Aug 2009 01:03:55 +0300, Yaron Sheffer <[email-masked]>

> protocol will be used by applications, which most likely will store the

> auth

> directly at the credentials. At which point I'm not sure this is so

secure

> any more.

Supporting authenticated mode, sure. But by definition, this won't work in

an unmanaged network... As for more controlled networks, it is questionable

whether hosts should be allowed to modify the firewall configuration at

all, anyway.

-- 

Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 05 Aug 2009 08:40:09 +0200

> IPv4, I think it should default to authenticated firewall control.

We must live in different planet. Because on my planet, most people

wouldn't know how to authenticate to their firewall. IPv6 is supposed to be

at least as easy to configure as IPv4...

-- 

Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 05 Aug 2009 08:44:32 +0200

On Tue, 4 Aug 2009 15:57:34 -0700, james woodyatt <[email-masked]> wrote:

> The most like scenario is applications soliciting any-source

>From this discussion, I guess so.

You might mention that RFC5389 only works for UDP while at it.

-- 

Rémi Denis-Courmont

---

From: james woodyatt <[email-masked]>
Date: Wed, 5 Aug 2009 06:32:30 -0700

On Aug 4, 2009, at 23:44, Rémi Denis-Courmont wrote:
>> [...] The point of allowing passive listeners to solicit any-source  
>> incoming flows with something like ALD has *always* been to make  
>> more wasteful techniques like RFC 5389 modulo NAT completely  
>> unnecessary.  Does this need to be spelled out more clearly in the  
>> draft?
>

Sigh.  Okay, I'll whip something up.

> You might mention that RFC5389 only works for UDP while at it.

Section 2 [page 4] seems to disagree.

>> The on-the-wire protocol described here is changed only slightly  
>> from classic STUN.  The protocol now runs over TCP in addition to  
>> UDP.

---

From: Mark Baugher <[email-masked]>
Date: Wed, 5 Aug 2009 10:01:33 -0700

> at least as easy to configure as IPv4...

A half dozen years ago, most home network wireless LANs in the US were  
open.  Market surveys that I saw from that time indicated that a lot  
of people would prefer that their networks be private.  Today, home wi- 
fi networks are mostly private, at least in the US.  AFAICT, the vast  
majority of people who are running their wi-fi networks without  
privacy do so because that's the way they want to run it.  Last week,  
I heard that a major US service provider is going to ship a wi-fi CPE  
with wi-fi privacy turned on by default.  That's progress as most  
gateway/router vendors don't do that today because it could result in  
a lot of service calls given that people can be running WEP, WPA or  
WPA2 on client devices.  I expect to see more providers and vendors  
ship their wi-fi products with privacy turn on by default, and who  
therefore expect their customers to authenticate to a wi-fi/router as  
part of the process.  So I think your statement above is shortsighted  
for at least this reason.

There is innovation taking place in home network access controls - WPS  
is one attempt by vendors to provide usable security in an unmanaged  
environment.  I know of a few other organizations that are designing  
security into their home networking services and not interpreting  
"unmanaged" as meaning "insecure".  It would be shortsighted to design  
a firewall control protocol that does not at least have access control  
as an option.

Mark

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 5 Aug 2009 21:04:39 +0300

Le mercredi 5 août 2009 20:01:33 Mark Baugher, vous avez écrit :
> I expect to see more providers and vendors

If the host operating system is authenticated to the CPE at layer-2, why the 
heck should it re-authenticate at layer-3? To me the big problem 
_specifically_ with UPnP is that any random application can use it and 
complete non-sense stuff with it like redirect any port to any IP and port.

As a counter-example, if I recall correctly, ALD can only redirect ports to 
the host that request it, and requires system privileges on the host (as it 
runson ICMPv6).

> a firewall control protocol that does not at least have access control

I already said I am all for having authentication as an option. But 
reallistically, I doubt it can nor should be enabled by *default* on 
*unmanaged* networks.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Mark Baugher <[email-masked]>
Date: Wed, 5 Aug 2009 12:11:21 -0700

I did not say anything about layer 2 or 3 or UPnP.  I'm not interested  
in holding
a beauty contest for the various ways to do firewall control.  The  
point I'm
trying to make applies to all of them.

That being said, we seem to be in agreement for having authentication  
as an
option for any firewall control.  I would add that to R41.

Mark